So,
I run a rental car company, and I want to integrate my service into a third party website - where people will be able to rent cars directly on the third party website. How can I integrate my service on the third party website efficiently? I am thinking that an iframe might be the best way or some sort of javascript call ... but I need the best way to integrate my service so that the third party site has to do less coding as possible.
I want people to check a box on the third party website if they want to rent a car and then a form pops up asking the customer for their payment details, then that information gets sent to my site, and my site processes that information and confirms the payment.
So basically, I was envisioning,
Person clicks a checkbox on third party site
Third party site sends information about the person to my site
I use that information to send back a payment box with price details
Person submits payment information on third party site
My site gets the payment information and processes the information
My site sends back status response to third party site.
The problem is, if the customer is a repeat customer, I would like the third party site to send me identifying information about the customer that will allow me to discern that she is a repeat- and thus charge her without her having to put her credit card details in the payment box.
In cases like this, its a lot more affordable, and sometimes more efficient to build a white label version of your product thats hosted on the same service as your primary product. This way all the functionality is essentially the same, except your slapping someone else's name on it and saying its powered by your company somewhere.
One key reason I suggest this is site to site transactions leave a lot of moving parts that can be tripped up through malicious means.
Take paypal for example, when ever you pay by paypal, what happens? You click the paypal button on the third party site, and it redirects you to the paypal site itself. You can do similar, you tell your 3rd party to submit a form like they would on any other site, and that posted data what little there will be as you want it all confirmable on your side so it leaves the door a little more closed to prevent someone from just changing the price or something. Anyway you take that posted data run it through your filters, compare it to whatever offers your allowing your 3rd party to do, and then process it all on your side. then when all is complete, you turn around and redirect back to there site and a thank you page.
Just food for thought
If you are going to implement a security so a hacker can't bog down your database with false orders use a shared secret key with which you encrypt the posted data to a hash, and then compare it on your side.
For example
$data = "color=blue|type=mazda|days=3|clientID=john#doe.com|etc=somedata";
$secretkey = "213098snxlkds_ljlsk3545";
$hash = hash('sha256',$data.$secretkey);
echo '<form target="someiframe" target="http://www.domain.com/bla/die/bla">
<input type="hidden" value="'.$data.'" name="data">
<input type="hidden" value="'.$hash.'" name="hash">
<input type="submit" value="Order the car Now!">';
Then at your side where you recieve the data you use this code
$secretkey = "213098snxlkds_ljlsk3545";
if(hash('sha256',$_POST['data'].$secretkey) === $_POST['hash'])
{
$process = explode('|',$_POST['data']);
foreach($process as $piece)
{
$vars = explode('=',$piece);
$Data[$vars[0]] = $vars[1];
}
}
This way if only you and your retailer have the hash, you can always verify that the retailer is legit and not some cheapchate trying to bog you down.
Having your service on third party sites means those sites are going to have to communicate with your app/site. On top of that, you want the users to be able to pay on the third party sites too, so you will be sending sensitive data back and forth. For that reason, I suggest you first get/integrate SSL.
Once you have that, you need to setup your own API. I know it probably sounds like a huge task, but it's actually not if you don't require much data and validation (returning loads of error codes and stuff).
So a quick example:
Let's say I have a website that people can login/register to. But I want users to be able to register to my site, on a third party site (like you want users to purchase goods from yours).
What I do here, is:
Create a basic script that will listen for any requests that third party sites will call. We shall call this one api.php:
//so we listen for POST params to be sent. These params will have users details stored in them
//so first check if all required params were sent:
if ( !isset($_POST['firstName']) || !isset($_POST['lastName']) || !isset($_POST['email']) )
{
exit();//because some/all of the required data is missing, we're going to stop right here xD
}//end of required data missing
//so if we get to this point, we know that the correct params have arrived
//so now you can do your registration stuff
//validate data (check if email is correct, if its been used before, ect ect)
//throw the data in the DB
//and if you need to, return some JSON status code
echo json_encode(array('status'=>'OK'));
That right there is an API. Very basic but still an API. So now you just tell the third party sites to post their info to "https://yousite.com/api.php" and it will return a status code, and the registration is completed.
I know that's not a very good example, but I hope you have managed to get the point.
Actually, most websites do this anyway. Even without the use of third party sites. When users register to a website, their data gets posted to some page. So I guess you could just POST data to your original signup/purchase/login page..
There are many different ways that you could approach this, but I think the simplest might be to have a simple JavaScript API that the third-party integrator can use on their website. Your JavaScript can set up the checkbox (for instance, attached to a div or form that the integrator specifies) and rig it so that when the user checks the box it opens a popup pointed at your site. You can then process your transaction from within the `popup.
This would be fairly comparable to how a basic Paypal integration works, where a user throws a Paypal button onto their site, and then when the button is clicked it opens a new window that points directly to Paypal's site (because as a general rule they cannot collect/accept payment or identity information directly from the third-party website) and passes a handful of parameters describing the transaction (payment amount, recipient, item details, etc.).
So for instance, a third-party might integrate with your service by first including your JavaScript file, like:
<script type="text/javascript" src="http://carmonkey.com/api/v1/MonkeyCar.js" />
...and then they might add some boilerplate code to hook up the API to the desired portion of their site:
<script type="text/javascript">
var options = {"container": "#someDivId", "userFirstName": "John",
"userLastName": "Smith", "rentalDate":"8/8/12", "duration":"7"};
MonkeyCar.drive(options);
</script>
Then your script needs to take those options and use them to add your checkbox to the target container element, and to configure the checkbox so that when the user click it a popup window opens to the appropriate URL on your website. So you might add something like:
<input type="checkbox" name="_monkeyCar" value="true"
onchange="if (this.checked) {MonkeyCar.open('http://carmonkey.com/reserve?fname=John&lname=smith&...');}" />
Book a Rental Car
Then once that happens the user can complete their rental car booking as normal, since the popup is just running a normal browser session with your standard website.
If you wanted to get fancy you could also add-in a feedback loop so that the JavaScript API running on the third-party page can get updates about the transaction status and detect when a transaction completes/is canceled and update the hosting page with the status.
Related
Introduction
Hello I'm going to sell a software using serial keys. Any person can go into my webpage and click on the paypal button to buy a serial key, they don't need to register.
What I'm trying to achieve
I need to let any person use the button and receive a serial key when the payment is done.
So the workflow would be something like:
Any person (non-registered) clicks on the button.
The paypal page shows up.
The user pays and gets redirected to a page that shows something like "Congratulations, here is your serial key: {{serialKey}}" and also receives the same serialKey via email.
What I tried
I'm trying to use Paypal's Smart Checkout but I don't understand how to implement what I need.
Right now I'm able to:
Render the button.
The button performs a request to my back to get the price (so the user can't change it and trick me).
The paypal page shows up.
On success it performs a request to my back.
On failure it restarts.
What I'm missing:
How can I check that the payment did actually succeed on the back, I mean that I received the money? Is there any way that I can post to paypal using the ID and see if I that transaction was correct?
Additional question
Is this the right approach? All I need is to let anyone click the button, pay and receive a serial key ONLY if the payment was correct. Right now it seems too complex for what I need. I don't understand everything I see on the paypal docs, if you follow it line by line the examples don't work, you have to adapt a lot of the code and I'm not sure about what I'm doing.
I also read IPN's docs but using it I won't be able to redirect the user because everything would be done in the back without the user even knowing what is happening.
Final text
Any help is appreciated. I'm asking here because I saw a lot of another questions about paypal like this one that were upvoted.
The most robust approach is to combine the PayPal Checkout front-end with a v2/orders backend for payment setup and capture.
create order
capture order
This way the capture happens from your server, so you have an immediate success/failure API response -- and can immediately do whatever you need to do to handle the business logic of the digital good purchase (serial key activation/distribution)
Once you have everything working well for the happy path, don't neglect to handle funding source failures, so that if the capture fails due to e.g. the buyer's first card being declined, this is propagated back to the UI and the buyer can select a different funding source.
I sell a (very cheap and dynamically generated through PHP) file of data online. For the payment, I use a basic PayPal button.
This has two advantages I want to keep:
PayPal is known, and people are not afraid to proceed to payment, as they are on PayPal website when they pay (they get redirected to my website at the end of the process, and the file automatically downloads).
I don't need any SSL certificate on my website (quite expensive).
This has several drawbacks, I would like to be fixing:
As the file is dynamically generated in PHP, I would like to be choosing the price and the currency dynamically (according to many parameters; currently the price is fixed).
In my JavaScript, there is POST action, with a hidden "return" parameter (the URL customer get redirected to once payment is successful). If you know this URL, you can get the file without paying. This is a big security flaw here in my implementation (even if most of my users won't know how to inspect client code)
I understand I should be using the PHP PayPal API rather than the basic PayPal button. The workflow I imagine is:
a PayPal button on the page when clicked, triggers a server side PHP script.
this PHP script decides of the price, contacts PayPal with the return URL (not available on client side) and redirects the client to this payment page on PayPal.
the client pays in PayPal secure environment and, once payment is successful, gets redirected to my website with a temporary authenticated token (?) so he cannot transfer this URL to someone else and the file download happens.
I am a little lost with the PayPal documentation. Could you confirm my architecture principles and provides me some sample PHP codes in order to achieve all that?
Other questions: I currently have a basic PayPal account. Do I need I business account? Do I need an SSL certificate? Do you know good alternatives to PayPal to do all that? Google? Visa?
I need to add payments to a website I'm working on and I'm not sure what to do. On the website, users will be able to purchase virtual points. So once they pay, their account will be credited with x number of points.
I came across this tutorial on IPN http://phprocks.letsnurture.com/paypal-ipn-with-php/ which I used, and was able to do a few tests using the PayPal IPN simulator(https://developer.paypal.com/developer/ipnSimulator). Everything went well and the user's data was saved to the database after the "payment".
However someone suggested another way to handle payments. Using this http://blog.scrobbld.com/paypal/protecting-your-payments-with-ewp/ tutorial which encrypts the payment.
In the second tutorial the author mentions this:
"If they use Firefox, and have installed Firebug, it is more than easy to edit the DOM of the page, and post that off to PayPal instead. So instead of having the amount at 12.99 , I might set it to:"
<input type="hidden" name="amount" value="0.99">
but doesn't this if from the first tutorial take care of this aspect? Or does the encryption from the second tutorial offer more security for the payment?
// 3. Make sure the amount(s) paid match
if ($_POST['mc_gross'] != '0.34')
{
$errmsg .= "'mc_gross' does not match: ";
$errmsg .= $_POST['mc_gross']."\n";
}
So if I understand this right, I can use the ipn listener class from the first tutorial, together with the encrypted payment from the second tutorial?
Within IPN the transaction has already occurred. So if it doesn't match you can send yourself a notification, automatically refund the payment, or handle it however you want.
A secure button, though, whether encrypted or hosted by PayPal (which is how I prefer) would not show the pricing data in the button code at all, so there's no way for anybody to even make a payment without the correct pricing.
So you could use both together, but the logic in the IPN really would be obsolete if you're using secure buttons in the first place.
The key phrase in Andrew's answer is "has already occurred" (IPN).
If you can actually verify the pricing beforehand, aside from opting for encrypting things, you could use Express Checkout where data is handled server side instead of an HTML form that POSTs directly to Paypal as shown in the sample.
This way you can treat IPN more like what it really is - a "messaging" service based on events in the transaction, rather than making it part of the transaction (where you somehow need to invalidate transactions after the fact).
While "invalidating" (credit/refund/cancel) transactions do occur normally, IMHO, it "should" be because of your business rules (instead of some validation issue, like dealing with tampered data).
"If they use Firefox, and have installed Firebug, it is more than easy to edit the DOM of the page..."
Tampering with HTML form data is an inherent risk in all <form /> and all modern browsers have internal tools (Firefox, Chrome, Internet Explorer) to inspect everything it ("client-side") is involved in. That is why validation (both client and server side) are required in any time of web development.
Hth..
I'm working on setting up a page that will display some information to the end-user after they make a purchase through PayPal. This page will have quite a few different tasks that it will need to execute to ensure the user receives what they had paid for, this mostly includes displaying information for the user in-case something goes seriously wrong, for example: The email containing product information is never sent.
In this event I would like to instruct the user to fill out "X" form providing their custom transaction id, however I don't know how I'd pass that custom transaction id to the thank-you page from paypal.
I know how to use the IPN, and I'm rather familliar with it. I've always used it to send emails, etc; However here, considering I'm selling a virtual product, I need to make sure it's delivered automatically, and providing enough information so that any problems can be dealt with accordingly.
IPN itself is all you need. You can generate email notifications with a download link or an attachment of the digital item that you're selling and it will be delivered in real-time. It will also help you handle things like e-checks correctly so that the goods aren't delivered until the payment actually clears as opposed to when the first transaction (the pending e-check) comes through.
If you do want to display data on the thank you page (assuming you're working with Payments Standard) then you can use PDT, which is very similar to IPN except that it's intended to send data back to the thank you page. This is for display purposes only and is not recommended to be used for updating the database, sending emails, etc.
Yet another option would be to move to the Express Checkout API. That way the checkout flow will always finish on your site without setting up any auto-return or PDT features, and you can do whatever you need to do in the thank you page code very easily. Again, though, it's still recommended to use IPN for final post-payment processing so that you can handle things like pending payments.
I got a simple Digital Goods Checkout to work in Sandbox mode. I have a "Pay with PayPal" button that I can click which pops up an window for logging into PayPal. After that it redirects me to my purchasemade.php script, and from there I can successfully download a file.
My problem is that on my website I'm going to sell many products, so I need to know which product they want to download when they finish the purchase. Each product has a unique ID, so I thought I'd pass that ID as the item number in the HTML form as a hidden field named "item_number". However, I don't know how to read that value once I reach the purchasemade.php.
How do I read values passed in POST in the original form? Otherwise, what's the best way of identifying a product? I'm using PHP as my scripting language for this project.
If you're going to stick with Payments Standard I would recommend using IPN to deliver your digital goods. You could use PDT (which is very similar to IPN) to send order data back to the page the user gets redirected to, however, there is no guarantee they will make here even with Auto-Return enabled in your PayPal account.
Alternatively, you could use the Express Checkout API instead of Payments Standard. This method guarantees the user will make it back to your site prior to completing payment. This will allow you to utilize session variables so you can present the download to the user on the thank you/receipt page.
Still, though, I think IPN would be your best bet regardless of which way you go. You can use it to auto-deliver the digital goods, send out general email notifications, update your database, hit third party web services, etc. all in real-time.