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.
Related
I've been developing a marketplace type platform. Implementing PayPal Payouts seemed to be perfect for dealing with commissions. Especially being as PayPal will be handling all payments too.
I've successfully developed this part of the system. Inc. the webhook and verifying transmissions.
Now I wish to get my eBay sales info into my system. So that we can see it all in one place and have the system work the commissions out for those sales too. Having just invested the time into learning and implementing this PayPal API integration, it would be nice to use it for getting this data too.
So having tested the sandbox app thoroughly for the Payouts, I configured the live one. This is in my PayPal developer account where the app settings are. I've done nothing in my main Paypal account. Am I meant too?
My live webhook URL is just set to log all received data from PayPal. So I waited for a eBay sale and went to check the log but no data received? Am I misunderstanding this? The webhook is subscribed to all events.
The Drupal Commerce shopping cart I'm using already implements a IPN. Is it the IPN that I need to be thinking about? I'd prefer to not interfere with it to be honest, to keep future security updates safer. That said, I suspect there will be a way to extend it.
I guess the actual question is - what is the easiest way to get eBay sales info through PayPal?
Any help would be much appreciated.
eBay has their own system for that called Platform Notifications.
If I'm working with payment data, and I just need extra data from eBay, I will typically start with PayPal IPN / Webhooks and then use the eBay APIs within my IPN app to pull and push data as necessary.
Of course, depending on the scenario, you may decide to build out your primary solution inside of an eBay Platform Notifications app, and then make calls to PayPal APIs within that if you need to pull/push data.
I have one requirement in which I need to develop Facebook messenger bots and implement payment for product from bots.
Has anyone experience with payment with bots and its approval by Facebook?
As I know currently it only has a receipt structured message that you can use for sending receipt. But there is no any API supports for the payment, you could either make a series of messages between the bot and customers by using postback, but it's very inefficient and stupid, also insecure. So I recommend using an external link that customers can click it and go to your payment system.
I have developed a bot that has integration with Stripe Payments (which is really fantastic btw). I created a WebView that redirects to my payment processing page. I didn't have any issues with the approval. All I did was send them a demo of how I get card information and showed them that I'm not storing any specific payment information because stripe hides the actual info and gives me a token to process a payment.
I find Bot approval in Facebook is stringent but straightforward as long as you give them the information they need. That means giving them a DEMO on how you're going to collect information and make sure that everything is clear.
Our terms and condition also have some payment terms (cancellation, refund, etc). Although they never checked it, I would highly suggest to clearly state these items on the T and C - and of course, make sure they tick a box specifying they agreed to such terms.
Good luck!
I am working with paypal first time.
I have a product and I want to integrate paypal with it.
I want to achieve the following tasks :
Client comes to my website and select a plan,which is a monthly recurring plan.
Then client is redirected to Paypal for payment.
Client makes payment.
Return backs to home page.
I have gone through the documentation of paypal and I have the following questions.
What should I use REST API or Classic Sdk, as I want to create Recurring Profile,Work with EXPRESS-CHECKOUT and REFERENCE TRANSACTIONS.
I have customers all over globe and it is stated in the documentation that, for the customers in Germany and China , I have to use REFERENCE TRANSACTION.
Some where in the documentation of Merchant SDK it is stated that the classic API's will be deprecated, so is it a good approach to use Classic SDK
I also wanted to track the transactions(payment) made by user, so that I can show him the amount that is deducted in each month in his profile details.
Please suggest a feasible solution to my problem.
Thanks in advance.
Here's what I use. I went to Web Payments Standard and created a Subscription button. (I like the unencrypted variety, but you can encrypt if you want.) In there, you set the terms of the subscription, as well as where to post the IPN message. When the IPN message comes back, you deal with it. You'll get a subscr_signup at the start along with a subscr_payment. Then, on renewals, you'll get a subscr_payment again. What I like to do is store every verified IPN message in the database for my customer.
For handling the management of those subscriptions for things like tracking info, refunds, subscription cancellations, and voids, you'll need to use NVP API, which is a very simple API. If you stored in a database every IPN message with all those fields, then you should be able to pass certain fields of those to the NVP API in order to get what you need done.
If you're worried about longevity of the APIs, then don't. All they do when they deprecate APIs is stop giving you good docs on them. They still let those older versions run. If they didn't, there would be major upheaval on the web with web commerce products breaking all over the place. However, that said, if you want to prepare for the future, then get on the Braintree Payments API because PayPal bought Braintree and that's the future of their API.
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.
Well, I didn't really know how to call this...
I have been surfing PayPal's developer documentation for a while now, but there is nothing that speaks to me with direction as to achieving what I am looking for.
It's probably well documented, but I don't grasp it well enough yet to make sense while reading each part separately.
I have read about Preapproval, though it seem to require that I send the customer's browser to the designated PayPal address.
I have thought about creating a database with credit card information, but that is too scary -- so I am looking to see if there is a way for a customer to allow me to do unattended charges to their PayPal account, much like I would be able to do if I had a database with customer credit card information.
Any direction would be appreciated.
Yes, this is possible. There are two options:
PayPal Express Checkout with a Billing Agreement
This works similarly to Preapprovals (which is Adaptive Payments, a different set of API's). You would need to redirect the buyer to PayPal in order to accept the billing agreement, and from then on you can bill the user using to DoReferenceTransaction API.
PayPal DoDirectPayment (Website Payments Pro) with Reference Transactions
You would need to have an existing transaction, and instead of a billing agreement ID, you would submit a prior transaction ID to the DoReferenceTransaction API. You can then re-bill the user on the card details which are stored with PayPal (up to 1 year. assuming the card details are still valid).
Do note that both options require you having access to the DoReferenceTransaction API, which you will not have access to by default.
For further information on the API itself, see https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_api_nvp_r_DoReferenceTransaction
Important: You will need to call in to get Billing Agreements activated. Good luck finding someone that knows what you need (no really) :-)
You will eventually find someone who knows what DoReferenceTransaction is and then once you've finally found them they'll probably tell you they can only activate it in the sand box and transfer you to someone in the Business Office. They'll have to then submit it to approval with someone else. Est. Total call time 59 minutes 8 seconds.
The guy I just spoke with said he's probably handled only 2 call in a year about DoReferenceTransaction - so you may need to ask around. They have other subscription billing and that's not what you want.
Also realize that approval is not instant and you may need to have established history. The guy who helped me said this is the best number
888 215 5506. Be sure to explain why you need them carefully and try to reassure them you're legitimate. A reputable website behind the domain for your paypal email will probably help.
Good news: I applied for Reference Transactions Friday and was approved today (Sunday). This was for two accounts - one which had only been established the day before.
Thank you for contacting us about enabling reference transactions on
your PayPal account.
I am pleased to inform you that your request has been approved. You
can begin using this feature immediately.
If you have further questions regarding this email, please contact a
Merchant Services Specialist at 1-888-221-1161.
Sincerely,
AJ Merchant Risk Operations
I was trying to do this recently and I found this question with no luck because the Express Checkout with a Billing Agreement method is deprecated since January 1, 2017.
There is a new REST method called Vault payment methods that recently entered open beta and it's not in the official documentation (to this date), so I leave the link to Create transactions when your buyer isn't present, in case someone needs it.
The process it's explained in the documentation but basically, you need to create a payment token (the source can be a PayPal account or a credit card), and then use that token to capture the payment.