Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I want to allow users to be able to send a paypal invoice in 1-click to their client.
angelleye gave me his php CreateAndSendInvoice.php file that is supposed to do that, but how do I start using it, do I need an api key?
The key is each user would have to enter some sort of credentials to verify my app to be able to send out invoices on their behalf.
Does anyone know how to do this? (website is https://cworklog.com )
Honestly, I would recommend avoiding the actual invoicing API for now. I've been using it with a client of mine and it's very buggy right now.
If you pass your own invoice ID into CreateInvoice or CreateAndSendInvoice it will only sometimes be returned via IPN. PayPal can't seem to tell me why this is.
Also, if you need to re-send invoices it can be a pain. SendInvoice only works once. You will get an error if you try to use that to send the same invoice again. Your only option at that point is to use the InvoiceURL returned when you first create the invoice.
This would be fine except that when this URL is used it forces a login to PayPal to view the invoice so guest checkout (paying with a credit card instead of a PayPal account) cannot be used this way.
Also, GetTransactionDetails is not returning the invoice ID for PayPal invoices either. I tried to use it as a work-around to the IPN issue and was shut down on that idea.
I would honestly recommend you just setup your own invoicing system. It really wouldn't be that much more work than building actual invoicing API requests.
You could let your users setup their invoice items and basically create an invoice in your own database. Then generate a basic HTML email with a pay button that points to a URL on your server. This URL can pull all of the order details back out to display an invoice to the payer on screen.
You can build Express Checkout into this for the payment processing and all of the issues I mentioned above wouldn't get in your way.
You can use the Permissions API to allow users to grant permission for your app to make calls on their behalf. Users could also do this manually through their PayPal account profile under "Request API Credentials." Instead of creating their own they would choose to Grant API Permissions and then enter your API username along with checking boxes for the permissions they'd like to approve.
Answer Summary:
Setup your API calls on the sandbox so you have a working demo.
Submit your application to x.com for approval. This will get you a live App ID to use against the live PayPal servers.
Have your users grant permissions to your app manually from within their PayPal account or via the API using the Permissions API.
Build your system to use the tokens obtained via Permissions API for your customers accordingly.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am creating a project whereby users are able to create webstores for their customers to purchase items from.
My current two thoughts are:
Payouts API whereby all customer payments will go to myself, and I will then use the Payouts API to send payments to users.
Have users enter in their API credentials in their user area so that their customers can send money directly to them using the Express Checkout API
Neither of these options feel optimal - the payouts API means I will be responsible for all chargebacks and payment disputes between customer and user. Forcing the user to enter in their API credentials is a slightly better solution however it would require me to provide documentation and support on how to create their API credentials.
I will likely go with option 2, but I'm hoping someone may be able to provide more options that I've overlooked or not seen in the docs. Thanks in advance.
Option 2 is correct, it is what all third party shopping carts do.
There exists a third option, the payee field, but you run into permission issues for refunds and authorizations. So Option 2 is the correct one for your use case. Each receiver should create a REST APP and enter the ClientID/Secret into your system.
You mentioned the "Express Checkout API" so you might be using something old/classic, which you should not do. See this front-end demo pattern of Smart Payment Buttons: https://developer.paypal.com/demo/checkout/#/pattern/server
Notice the two fetches to '/demo/...' endpoints, which must be replaced with actual routes on your server. The first should create a v2/order and return an OrderID. The second should capture that v2/order after a payer has approved it.
I'm trying to integrate with Braintree using the javascript SDK and the dropin plugin, but there is something I find hard to understand.
It seems that the user gives a free permission with his "payment_method_nonce" to charge his credit without him knowing how much he is being charged for. let me explain:
Looking at the flow overview:
1. Client request an authorization token from my server.
the server then creates a new token using his unique "Braintree SDK and credantials",
the sever send the token back to the client.
The User enters his credit card number and submits -> client sends a request to Braintree server.
Braintree server returns an "payment_method_nonce" to the client.
The Client send the "payment_method_nonce" to my server.
Using the "payment_method_nonce" my server create a transaction, set a price to charge and send a request to Braintree server. The user doesn't knows how much he was charged since the request was sent from the server.
When I worked with Paypal directly (without Braintree SDK) the user was redirected to the "paypal domain" to complete the transaction.
there he was presented with all the details about the transaction, price and all, but with "Braintree" this step is missing.
what am i missing here?
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support.
The Drop-In is a pre-made UI for accepting cards and PayPal. It should not be used as the sole part of your checkout.
You are responsible for incorporating the Drop-In UI into an existing checkout workflow within your store, which should include confirmations of meaningful transaction information such as address, amount, etc. By contrast- PayPal, who has security concerns for their account holders, includes some checkout steps to their UI as a means of providing trust and security to their customers.
I own a personal PayPal account and am coming up with the design for a personal financing application. I intend to use the APIs provided by PayPal to fetch recent activity on my account to automate some of the information entry (at the moment, most of my transactions go through PayPal).
I've rooted through the API documentation, and I haven't been able to find any sort of endpoint I could use to fetch my recent account history.
I did find a question previously asked and answered about two years ago stating that the only way to do this was by getting a Premier account, which I'd rather avoid due to not knowing if there's any costs associated with such. I'd also like to note that despite my Personal status, I still get notifications on my Android phone stating that I've spent money.
Which brings me to the title question: does PayPal's API expose some endpoint I missed that allows me (the user) to programmatically browse my history, find new transactions, and mark them down with little input from me, or at the very least register to receive notice from PayPal that a new transaction has appeared?
You can pull transaction history using the TransactionSearch API. Then you can get individual transaction details using GetTransactionDetails.
You may also want to look into IPN, which will automatically POST transaction data to a URL you specify as a listener. That listener can receiver the data from PayPal and update your own database, send custom email notifications, hit 3rd party web services, etc.
I have created and submitted a Paypal application ( using the classic API). The application is in a conditionally approved state. Paypal reached out and asked additional questions which I responded back with details. The application does not use the Paypal API to make payments. It only reads transactions related data and shows useful reports and insights for users. The API permissions requested are
1.Obtain transaction specific information.
2.Obtain your paypal account balance
3.Search your transaction specific information.
4.Search your transactions for items that match specific criteria and display the results
I was able to get a live app id and also have the API username, password and API signature. However since our app uses Paypal oauth, the permissions part doesn't work . My guess is this is because the app is conditionally approved. Is this the right assumption? Also what is the typical timeline for an app to get approved? My Paypal account from which I created and submitted the app is a verified account. I have sent messages from within my developer portal to support but I haven't heard anything back.
So far we have been working with a sandbox account. The live application I created is in a different account than the sandbox account. I am not sure if this is an issue.Would be great if someone who has been through the process can confirm.
Unfortunately there is not really a "typical" time frame for app approvals as too many factors go into the approval process. The best thing would be to call in to PayPal to inquire on the status.
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!