I'm currently putting together a processing script for a website, and have run into a question that I can't seem to find a clear answer to. Paypal's documentation is iffy at best, and I do not use Paypal enough to discern the answer easily from the information they provide.
When a subscription is created through Paypal, they return two notifications in the first instance - subscr_payment, and subscr_signup.
My question is: Do future payments at the set data process as subscr_payment, or as recurring_payments?
Future payments are sent as "subscr_payment"
https://www.paypal.com/cgi-bin/webscr?cmd=p/acc/ipn-subscriptions-outside
Related
I´d like to notify to buyers when theirs credit card is about to expire and subscriptions would be possible cancelled or suspended.
As per PayPal documentation this is possible to archive using Webhooks (REST API) or IPN (NVP/SOAP Apis).
My question is:
Which is the best approach to get as much information as possible to notify to the buyer by email?
Thanks in advance.
Roberto.
Are you working with REST APIs to build your payment requests? If so, you'll have to use Webhooks.
If you're working with PayPal Standard buttons or Classic APIs, then you'll have to use IPN.
So that's really where your question lies. You don't really have a choice depending on which method you're using to integrate the payments.
Once you know which one you need to use then you can review the notifications themselves to see which ones will give you the data you're after.
I've been using the PayPal's IPN system for over several years. I have a PHP script that's been processing online eCommerce payments on my web site without any issues.
Today I received the following email from PayPal:
Update your integration before 1/18/2017.
Effective 1/18/2017, your PayPal Payments Standard (also known as
Website Payments Standard or HTML buttons) integration will be
affected by updates we’re making to enhance the checkout process.
We’ve identified your integration as passing either invalid or
incorrect data to PayPal in one or more of your payment buttons. To
ensure your payments continue to process, you’ll need to update your
integration as soon as possible.
What’s Needed
Please check out these FAQs for more information on common integration
issues. Additional details can be found in our Developer documentation
here.
Here are some of the benefits you’ll receive with your updated
integration:
sales blah-blah...
As always, if you need help or have any questions, give us a call or
visit our Help Center.
Thank you for being a PayPal customer.
I checked my integration script and it is passing their "most common problems" from here.
So my question is, did anyone figure out how to test your IPN script with their new update to know what exactly has been identified as passing incorrect or invalid data to PayPal?
I developed a Web Application that accepts payments via the ExpressCheckout API, for users to become a members.
Everything works fine.
I now want to extend my Web Application Services and offer my users with the possibility to buy items which are sold by third parties (my members).
The principle I would like to implement is quite simple: for each order, let the user pay for the item they choose and then transfer a part of the amount I received to the item provider, and keep some money for me. I would like to automate this process so that once I received the payment notification, I compute the amount of money to transfer to the item provider who might or not have a Paypal account (in other words, this means that I could maybe need to transfer the money to a bank account, using the IBAN/SWIFT data) and then proceed with the money transfer.
I tried to find a solution reading your documentation and came across the "chained payment" but the latter does not seem to be used within the ExpressCheckout workflow.
Also, since my implementation of the ExpressCheckout flow works, I would not like to have to find a totally different solution but rather extend it... if possible.
Could you please tell me which is the best solution for me?
In advance, many thanks for your help.
You could do 1 of 2 things. You could use Express Checkout with parallel payments. This means you could split the transaction up between different accounts at the time of purchase. The other option would be to just receive all of the funds into your account, and then when you are wanting to send money to the other accounts you could either use the Adaptive Payments (Pay) API or the MassPayments API to send money to the other accounts. Keep in mind you would have to send it to their PayPal accounts, you would not be able to send it directly to a bank account with either one of these API's.
I had the same issue and I got an answer from PayPal that it is not allowed to use Express Checkout to transfer money to your PayPal account and - at a later point in time - transfer the amount minus your service fee (which stays on your PayPal account) via Adapative Payments API to the seller's PayPal account. PayPal suggested to use Chained Payments API instead. All works fine in the sandbox, but once you need a Live APP ID from PayPal they will review your business case and deny it. At least that what happened to me.
I know that is old question, but anyway, I tried to find solution and was enable to perform the simillar thing like described in question. So, then I asked paypal about this, and they gave me advice to use SellerDetailsType Fields that 's called PayPalAccountID, description for this field is Unique identifier for the merchant. For parallel payments, this field is required and must contain the Payer Id or the email address of the merchant. It wasn't clear for me to use this field for solving my problem. Here is link https://developer.paypal.com/webapps/developer/docs/classic/api/merchant/SetExpressCheckout_API_Operation_SOAP/ I described field for soap request, for NVP it's called PAYMENTREQUEST_n_SELLERPAYPALACCOUNTID, but the idea is the same. I hope it will help someone.
Just running through the API to see if I can use Dwolla for web apps that require recursive billing - there is no API support for this, is there?
Thanks!
Michael- you mention above recurring was going to be added to the v3 API release.
Has this been delayed?
Also I sent a email to your posted email address between Dec25 and Jan.1 and didn't rcv a reply to a previous post on the endpoints for the Funding sources.
Did you rcv this private email concerning Clay Gulick's questions on GetSatisfaction?
These Funding source API's still seem to have lots of questions around them from the developer community and not much documentation on how to chain FORM processes with the oauth Token from REGISTER to FUNDINGSOURCE BANKACCOUNT ENDPOINTS
Could you answer the questions or have a Dwolla developer answer those -- most of the questions were on GetSatisfaction.
Both REgistering a user, REcurring payment streams and creating a Bank account and verifying it is critical for most of the types of transactions this community seems to be interested in - vis'avis' a single FORM UX process stream. These have been default ACH endpoints for a long time now. I am not sure why veridian isn't opening these up and creating less friction for Dwolla to create a ZERO friction user experience API for your 3rd party developers.
Thank you for answering our questions in advance.
Eric is correct. We're definitely planning to add an API for recurring/scheduled payments, but that won't happen until the release of our API V3, which will happen closer to the end of the year...
We are, however, about to remove the PIN requirement for the request money method, and so depending on your flow, this might help somewhat.
There is currently no API support for recurring payments, and I'm not sure if Dwolla plans to add it.
You may be able to do what you're hoping to via a regularly scheduled call to the API of the request method with the user's Dwolla ID or phone number, as documented here. The user will still have to "pay their bill" each time, but will be prompted to do so with a Dwolla request for funds.
PayPal states:
Note: If you have turned on Auto
Return and have chosen to turn on
PayPal Account Optional for new users,
a new user will not be automatically
directed back to your website, but
will be given the option to return.
But if some of the customers don't get "Auto Returned", how do I handle them programmatically?
Paypal does not guarantee autoreturn especially when Paypal Account - optional setting is on.
The right way to handle the integration is with Instant Payment Notification (IPN) option. Using IPN Paypal will make POSTS to your page notifying you of payment events. The following link explains the IPN process pretty well.
To summarize, you will write code that will trap posts from Paypal and then make sure to update your billing data accordingly.
Also, IPN messages might be slightly delayed.
Create a script (cron or what) that does check for such payments at paypal perodically (e.g. every hour).
Is this what you mean?
https://www.paypal.com/cgi-bin/webscr?cmd=p/mer/express_return_summary-outside
If not, you may need to be a little more specific with your question. Like - are you using paypal pro? How are your customers checking out? etc. And now that I read the answer below mine, I wonder if you are even talking about the payment process and not something else.