I'm using the same PayPal merchant account on multiple websites. Currently I'm using old-style PayPal links () with IPN notification.
Now I'd like to start using the PayPal Express API. But at least for a while I would have the old links still online on some sites.
The switch to PayPal Express seems to be per account. Will the old links and IPN continue to work ?
when you implement PayPal express checkout that will not hinder your PayPal links on whatever site you have them on. You can have PayPal Express Checkout with non-hosted button code on the site at the same time; no problem, at least while you're done with your testing, etc.
PayPal Express Checkout can be used across multiple sites; however APIs are only one per account. What this means is that if you want the funds to go to separate accounts for each site then you'll need a new PayPal account per site as you'll have to use different APIs with Express Checkout. That is the UserName/Password/Signature.
However you will have one IPN listener field for each account; so if you don't mind getting pinged for each site using the same IPN listener then you're fine.
You can just create specific prefix # for each site with the products themselves. Like store # 1 = 001Product# | Store # 2 002Product | etc. This will help differentiate IPN pings for each store and help you catalog it better. This is if you decide to use the same APIs for Express Checkout with the same IPN of the account. If so, you will have the PayPal button purchases along with the Express Checkout purchases you all the same data IPN wise and all funds will roll into the same account.
I hope I hit your mark on your question, but let me know if you need additional clarity as I'm happy to help. Have a good one.
Related
What's the difference between PayPal buttons and PayPal Express Checkout?
The second one seems more complicated than the first one to integrate in a web site. When I should consider to use Express Checkout rather than Buttons? What are the advantages?
PayPal Standard buttons are indeed quick and easy, but they are limited. One of the biggest issues with it is with regard to Guest Checkout, which allows non-PayPal account holders to pay with a credit card without creating an account.
With Standard buttons this is browser cookie based, so if anybody has ever signed in to a PayPal account using the browser in use, then the cookie will trigger and assume that the user will be logging in to PayPal. This causes the guest checkout option to be less prominent, and buyers often miss it, which results in lost sales.
Express Checkout uses the APIs which gives you more flexibility, including the ability to force the Guest Checkout experience if you want to regardless of any browser cookies. This can lead to increased conversion rates.
Another thing to consider is that with Standard buttons there is no guarantee the user will make it back to your site. Even if you have Auto-Return enabled in the PayPal account there is a delay, and the user could simply close their browser before they are sent back to your site. With Express Checkout the user has to return to your site before the process can be completed, so this gives you the ability to tie more post-transaction processing procedures into your checkout flow.
Adding PayPal buttons to your website eliminates the need to enter your shipping address. You only verify the purchase details and confirm by the user and it gets supplied by PayPal but in case of Express checkout customer still need to supply their shipping address .
Also in case of express checkout you make API call initially to PayPal and in turn PayPal gives you token id for the payment you are going to make and you use the token(which is unique for every payment) to subsequently authorize and capture the amount from PayPal account once the customer confirms the payment after logging into PayPal account.
We have been using the PayPal Checkout (v4) for a little while now, and really like the way it integrates. This is the system I'm talking about:
https://developer.paypal.com/docs/integration/direct/express-checkout/integration-jsv4/checkout-flow/
We are using this plugin to do the magic:
https://github.com/paypal/paypal-checkout
Anyway, as I said we have this all working fine when someone is sending US the money. However, we also have a tool on our site where "customers" can send money to sellers. For this, we currently have the Adaptive Payments system.
My question: How can we use the PayPal Checkout tool to let people send to a given email address, while still getting the callback for the order? (so we can enter it into our system, to track it)
At first I thought this wouldn't be possible - but I've seen this exact same logic on eBay:
Is this something that is publicly available? Or is it just a "PayPal-Ebay" thing? (as they are effectively the same company, so maybe have access to different tools than the general public do)
Thanks!
Here's another option -- the payee option in PayPal's REST api:
https://devblog.paypal.com/setting-payee/
Using this, you can set the money to be moved to whichever paypal account you like with just the email address.
The PayPal Express Checkout v4 is based on PayPal Rest API which does not support spliting or sending payment to a given PayPal account that is not the API caller. Adaptive payment is the right to do so in PayPal. The PayPal checkout on eBay is only for eBay, the checkout experience may look similar but it's using different product than the Express Checkout v4.
The basic integration lets you set up a button for a merchant using only their client id:
https://developer.paypal.com/docs/integration/direct/express-checkout/integration-jsv4/basic-integration/
So if you can collect the merchant's client id, you can set up a button to make payments to that merchant.
Hope that helps!
I new to paypal integration in asp.net . I found very difficult to understand the paypal api .
I under stood two types -
inline html form ( i.e is also called buy button )
payflow api
my questions are :
which one must be used for recurring payment ( subcription packages for end user)?
in first type , few sites suggested to use IPN for confirmation of payment. I want to know is it neccessary since without using IPN, also using notify_url we can confirm the payment success (as per my knowledge notify_url returns to your site when payment is completed at paypal site)?
for recurring payment , do i need to store user account details (i.e credt card or paypal account ) in my databas?
please do reply with you suggestion .
Thanks
1) You can do it with both, actually. If you want to stick with basic HTML forms then you'd be using Payments Standard, and they call it "Subscriptions". You can easily create a Subscription button from within your PayPal account.
If you're using the API then they call it Recurring Payments (or Recurring Billing). You would use Express Checkout for the PayPal signups, and Payments Pro if you want to handle credit cards directly on your site without any redirect to PayPal.
IPN is useful regardless of what integration method you're using, however, don't get it confused with PDT. PDT sends data back to your site's thank you page, or whatever final page you setup for it, and it only works with Payments Standard. When PDT is configured on Payments Standard, even with Auto-Return enabled, there is no guarantee the user will make it back to your return URL. IPN is very similar, but data will always be POSTed to your IPN listener regardless of whether or not the user makes it back to your site.
You'll also want to use IPN to handle updates for future payments on a subscription / recurring profile. For example, the actual payments, cancelations, suspensions, reactivations, etc.
The notify_url parameter you mentioned is used for IPN. Again, though, this is separate from PDT. A common mistake I've seen many times is when people have their PDT and IPN both set to the same URL. Then when people do make it back to your thank you page, the code actually runs twice. Once from the user actually hitting it, and once again from PayPal's IPN server hitting it. So make sure to avoid that sort of thing.
3) No, you will never save credit card details to your server. The subscription / recurring system handles that using the data that PayPal saves on their servers.
I am building website which requires customer to update paypal account.
Is there anyway to check the reality of customer's account?
When my customer fill out their paypal account in my site, I want them to be directed to paypal login page to login and paypal will return the result.
Does paypal api support this situation?
Pretty much any implementation of PayPal you choose would follow the flow you mentioned.
Payments Standard would allow you to create basic buttons or create an HTML form and POST directly to PayPal to process. It would send the user to PayPal for login and approval to complete the payment. The transaction details would include the payer status (verified or unverified) as well as the address status (confirmed or unconfirmed) and lots of other details about the order.
Express Checkout is basically the API version of Standard, but it's much more advanced and open to integrate in the way that works best for your site or application. In this case, some of buyer/transaction data is available during the process within your app through API requests and responses, and then you can also get to it via transaction details after the fact just like payments standard provides.
Another option would be to use Adaptive Payments, but if you're doing a general payment of any kind you probably don't need that. That's what you would use if/when you start wanting to split payments among multiple receivers within the same transaction, setup preapproval profiles, etc.
If you happen to be working with PHP my class library for PayPal will make the API calls very simple for you.
You could do what PayPal itself does when you register. Send them a few cents and have them tell you how many when they get it. The payment itself will fail if the account doesn't exist, and telling you how many cents proves that they own the account.
I am looking to set up a recurring payment option for my website. I was thinking of going with PayFlow since it does not require expensive SSL. But I am not sure how to set up a recurrence payment where if the user decides to change the account type, we can automatically set up recurring payment for them to get charged next month. Not sure if this is possible?
A few problems, they charge almost $60/month and they require to have a Merchant Account (any suggestions)?
Can some one help with what type of service should I use? I am looking to not have credit card acceptance on my webpage because SSL is really expensive.
The webpage is in php.
PayPal Express Checkout does this, and more. While Payflow Link is generally a good and robust solution, Express Checkout has a bit more to offers in terms of features. It also redirects your buyers to a PayPal landing page for entering their card details.
I assume you can simply delete / disable a recurring payments profile and set up a new one whenever someone switches plans, right? In that case you'll want to look at the CreateRecurringPaymentsProfile API.
Have a look at https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_api_ECRecurringPayments and https://www.x.com/docs/DOC-1168
Do keep in mind however, that recurring payments on Express Checkout only works with existing PayPal accounts. Someone who doesn't have a PayPal account yet, will have to create one during checkout.
Paypal is usually a great solution. There is no problem with billing recurring payments (subscriptions).
You can read all about it here:
https://www.paypal.com/pdn-recurring