The payments we gather on our website are for online subscriptions and registrations for conferences. In both cases, we want to gather absolutely all information other than the payment information ourselves, and ideally pass some of it on to PayPal (so users don't have to fill in name, address, etc. twice).
I know there are solutions where the information is gathered by the server itself and then redirected to PayPal via a web services call but that's not an option, unfortunately. All secure payment information gathered has to happen off-server due to network policy.
In addition, not every form will need to be processed using PayPal. Some people will be paying via check, etc. so they shouldn't be sent to a payment page at all. Most solutions I've looked at have a "Pay with Paypal" button, so I assume a form post is necessary to go to the PayPal site, but ideally we'd want to get there via a 302 redirect. Is that at all possible? (I'm aware we could do something like a form that was auto-submitted by JavaScript but I'd prefer to not go down that route).
Whichever system we implemented would need to handle recurring (periodic) payments also.
Paypal has something called Payflow Pro. They bought it from VeriSign a few years ago.
You can use it to do a full integration with the paypal api. So that the user enters their payment details on your site, and your backend code submits the transaction to paypal's servers. Paypal will then give you a transaction id back. Keep the transaction ID, chuck everything else (like the card number) out the window.
We have several clients that use Payflow Pro. It's very good and easy to use api.
I'm not entirely sure I understand the full scope of your question, but I think I do. I've coded a number these conf. registrations (though I have not interfaced with PayPal...rather iTransact and Plug'NPay) and in my applications, I had to read through the API documentation for the system being used (PayPal in this case). Then I logged into the payment gateway and usually they have an html form generator. All this does, of course, is returns an html form with the fields labeled appropriate to their API (so the billing name and address carry over from your system to PayPal's and the user doesn't have to re-enter their information), shows you what hidden fields you'll need(like cutomer_id, etc) and the form POST path.
Then what I do is I have the user register, preview their order details on another page (where you can choose to drop their info into a DB or wait until AFTER their credit card is processed) and then upon confirmation, they go to PayPal, pay with either credit card OR check (the options always exist) and when they hit confirm, the passback URL you put into a hidden var somewhere, takes you to a custom Thank You page (and hopefully processing script to capture successful transactions) which can be hosted anywhere on your servers.
It's pretty simple, just a bit labor intensive at first as you try and figure out the new form variables specific to a payment gateway API.
Hope this helped!
Related
I have browsed this forum and been through the PayPal documentation but I am confused. I know what I need but cannot work-out how to specify it for my coder.
We have a .Net application that runs on our internal network. We use this application to create customer quotations. These quotations are emailed to our customers. I simply want the application to be create a link that I can send to the customer such then when it is opened it takes them straight into Paypal and allows then to make a payment for the quotation. Or maybe the link is embedded into the body of the quotation that I send. Either would be fine.
I know of programs that do this (Sage Line50 does it with Sagepay rather than PayPal) but I cannot get my head around the process. Most of my research is talking about taking payments from an external website but trawling through the PayPal documentation it looks like it should be possible. But I cannot figure out whether I need Smart Buttons or PayPal Me. The key thing is that I don't want to force customers to have a PayPal account so guest access must be an option.
Smart Payment Buttons would be ideal, and offer the best payment experience to your customers. However, they require your own server on which to host some HTML/JS for them. They do not offer a link that can take the customer directly from an email to a PayPal checkout.
I recommend using Smart Payment Buttons, if you are able to host one. The flow is:
Email -> page on your server with Smart Button -> PayPal payment.
The key thing is that I dont want to force customers to have a PayPal account so guest access must be an option.
PayPal.me does not meet that requirement
If your requirement is truly a link that proceeds directly:
Email -> PayPal.com checkout for payment (no webserver of yours) ... well, there two solutions for this.
One is to use PayPal invoicing, which can be emailed directly by PayPal, or can be a link which you share yourself (via your own email). A PayPal invoice can be created manually via: https://www.paypal.com/invoice/create . Or programmatically via the invoicing API (see developer.paypal.com)
The second way, which may work fine but is a very old web 1.0 way of doing things, is to start by going to http://www.paypal.com/buttons and create a Buy Now button for an item named "Placeholder", amount "777.88". Expand the section "Step 2", and uncheck the option to Save the button at PayPal. Do not change any of the customization options, particularly ones that add menus or input fields.
Once you have generated the code, click the option above it to remove code protection, and then switch to the E-mail tab.
This will give you a plain HTML link with a description and amount that can be set dynamically by your developer when sending your own email. Additional useful variables, such as invoice (for an invoice number that is unique for what is being paid for, and can't be accidentally paid twice) are documented here.
Again, Smart Payment Buttons should be preferred if you have a web server to act as an intermediary. Here is a skeleton demo of the experience.
I am developing software that will allow a user to create forms based on draggable controls, in the fashion of, say, an online survey. This is how it's supposed to go:
User A makes a form.
User A sends said form to User B.
User B fills out and submits the form.
Here's what I need: I have a page that allows User A to set up a PayPal payment for each entry into a form. This would require User B to successfully pay with PayPal before he could submit his entry. I do not want User A to have to do anything more than specify the amount/entry and his PayPal email.
My problem comes in after User B has paid for the entry and decides to close the tab instead of returning to the store. This doesn't allow me to submit the form. How can I create a full-proof method to assure this doesn't happen?
Things to keep in mind: Assume User A does not have IPN/Auto-Return enabled and potentially isn't a business account.
If you are using PayPal standard there is no fool-proof way to do this since the user leaves your site to do the transaction. PayPal has other offerings that claim to allow this, but they may expose you to PCI-DSS compliance issues.
A better choice would be to use a system like Stripe, where the user never really leaves your site.
So, I've found that if you use the notify_url html variable, the merchant does not need to enable IPN. Therefore allowing me to tell PayPal to always post to my server.
I have looked around SO for this but I can't seem to find anything like it.
On my service, I wish to charge on a per-month basis depending on how many users my clients have.
So this question is split up into two parts.
What I want to know is it possible for a client to use their own paypal account (without entering any CC details) with conjunction with CreateRecurringPaymentsProfile via the NVP, I have looked through the documentation and can not discern anything. So clearly it is not possible to do it via NPV - From what I've seen so far.
i. If I do an Express-Checkout Subscription, I can do 20% change on total amount every 180 days (I DO NOT want to do this) - I want to be able to get the Profile via the IPN and then modify the monthly amount on as-need basis
ii. There was some mention of Referenced Transactions, but the Documentation is very confusing.
So say there is a way to create a recurring payment subscription via a PayPal Account on the PayPal website, next step is to be able to update the Subscription via UpdateRecurringPaymentsProfile NVP command.
While I am happy to pass on CC details (which already works great), I am just wondering if it is indeed possible create a button, which would create a Subscription - once on success an IPN request is sent back with the ProfileID which I can modify the Billing Amount by NVP.
So TL;DR;
The current flow I have
Register on our website
Enter CC Details
Backend submits the data to PayPal and if passed - continues on.
On any Account modifications, update Profile Monthly Amount Automatically.
The flow I want
Register on website
Click on an Authorize Button Redirected to PayPal
Login to their PayPal Account Create Recurring Profile.
On any Account modifications, update that Profile Monthly Amount Automatically.
edit to add - this is all working now, had to contact and harass PayPal directly for a lonngg time.
I'm a little confused because it sounds like you answered your own question, but then said that's not what you want..??
Express Checkout does exactly what you outlined at the end of your post, and it triggers an IPN just like any other PayPal transaction. You are indeed limited on how much you can adjust the amounts of profiles created with EC, though, just like you mentioned with the 20% every 180 days. If you create profiles with Payments Pro (DoDirectPayment or PayFlow) then you're not limited and you can adjust the amounts however much you need to whenever you need to.
Reference Transactions and Preapprovals may be something to look into as well. I actually wrote an article about what they are and how they differ from each other awhile back that you might be interested in.
Question:
How can I have a visitor to my site pay to a 3rd party PayPal account (one I do not have access to) and have PayPal return the visitor to my site, confirming that the payment was a success (while requiring no special setup or confidential information from the 3rd party account)?
Details:
My company provides a service to clients of other organizations, however, we collect payment directly from those organizations (and not from their clients). In our particular case, if the organization's client opts to use our service, they will pay the organization they are part of (and not us) - the entirety of their payment goes to the 3rd party organization (the value of the payment may vary, but it will always be billed as a single item). The only information we need from this transaction is: the ID of the client (a value from our database), and some type of verifiable confirmation (ideally, a dollar value paid).
The flow is as follows:
Our site
redirect to 3rd party PayPal
return to our site with confirmation
Authorize transaction and enable service
e.g. thank you page with Next button
payment needs to be authorized before going to next page
We would like to implement this in such a way that the 3rd party organization does not need to set up anything additional in their PayPal account, and does not need to share confidential information with us (ideally, they should only need to share their PayPal email address).
Currently, we are exploring using the following:
Buy Now button
Set the notify_url field on the form
Setup an IPN listener on our server that will process (and verify) the transaction
The problems are two fold:
We have been unable to confirm that this implementation would not require the 3rd party
organization to setup anything in their PayPal account (e.g. they
don't need to setup IPN, since we are using a per transaction URL
and they don't need to share their API key).
IPN is asynchronous - so we will not receive the notification as part of the transaction flow (which complicates things, but if no better option exists, we
can make it work). Is there any synchronous approach that would
notify us of a successful transaction without requiring additional
credentials (e.g. PDT requires an identity token so does not appear
to be an option for us).
If there are any better ways to approach this problem, suggestions would be appreciated.
You can use Parallel or Chained Payments to send money to multiple recipients, be able to control where the buyer is taken to after completing the payment, and you would get an API response back right away telling you if the payment completed or not. Using the Permission Services API calls you can set up your account as a third party to the receivers so they wouldn't have to make the changes themselves.
You mentioned that you're looking into using Buy Now buttons through Payments Standard. That would work for if you're looking for a quick and simple way of setting it up. Define the receiver as the business value and the money would be sent to them.
By default, IPN is set to "off" in an account which means an IPN post will still be sent out if you define it with the "notify_url" variable. You may need them to enable IPN within their account if they've previously disabled the service. If the receiver already has an IPN URL set in their account it would be overwritten by the "notify_url" value you provide.
I'm using paypal website standard and passing my order id that is generated on my site via item_number field. I was wondering, how does paypal know that the content in the form has not been altered by user? For example, someone could just change the amount of $10 to $5 and paypal would not not have any way of knowing. I've doe this before with other payment processor, and they make me send them md5 hash of amount and some other data + secret key, but I am not sure if paypal has this?
Based on this article, I believe it depends on whether or not you are using "Payment Data Transfer". If you're just using a button, then you'll need to manually verify the payment amount before shipping. If you're using PDT, you should be able to verify the payment_gross amount sent back in the response from PayPal.
Your right -- in general you can't keep someone from altering your data. If you must use PayPal (yeah, I know, no monthly fee) so far as I know you have three options:
Let PayPal host your button data. But this gives you little control over the process.
Manually verify each transaction, checking price etc before shipping item.
Using their API to receive completed transaction to automatically check data.
Another thing to watch out for is calculation of sales tax. PayPal's approach was too simplistic for our needs, which forced me to take control of the checkout process.
See this link.
you should try to implement it using ipn, pdt is prone to not passing the variables from paypal to your website if the user does not press the "go to store" button. as what others had answered hosting your button would make it secure at the cost of flexibility. Here is a link on the variables that could be altered on hosted buttons https://www.x.com/people/PP_MTS_Haack/blog/2009/11/11/override-variables-for-hosted-and-encrypted-buttons , as you would look into the variables, you cant really change the important ones.