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 6 years ago.
Improve this question
I am developing a system that provides event signup/registration services. Event hosts should be able to offer online payment options to their customers via this system.
I need a scenario when event owner (assuming he/she already has proper PayPal Business account) configures the minimal amount of information in the system (like merchant ID) and then he's able to receive online payments without having to dive into technical details of the integration.
I have started with JavaScript button solution, but it turns out that it's not very customizable (for example I cannot change button title from 'Buy now' to 'Pay now').
Then I have spent some time researching Button Manager API, but it seems to be over-complicated to accomplish the task of just changing the button title.
Could somebody point me in a right direction?
You can easily change a standard button's image, it is simply an image URL in the client-facing code. If the javascript wrapper doesn't let you specify an image URL for some reason, don't use javascript buttons. Create your own based on an unhosted button generated at paypal.com by unchecking the step 2 option to save the button at PayPal as well as the You are viewing your button page's option to remove code protection. The "business" variable would then become your host's PayPal email or PayerID.
None of the above is the recommended route, which is to use the Express Checkout API and pass the parameter SUBJECT=hostspaypalemailaddress#domain.com (or PayerID) in your initial SetExpressCheckout call. You probably also want SOLUTIONTYPE=Sole if this is your only payment option.
For onboarding new hosts you can use the Permissions API.
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.
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 5 years ago.
Improve this question
I have a simple "pay now" PayPal button on my website. I also have a server listening for IPNs. The IPN handler basically updates the validity of my user´s account.
But what´s hard for me to do is the correct handling of the IPN.
The basic handling with the validation step is no problem.
But I also need to check and handle the transaction type and payment status.
In the PayPal docs there are many different values for different cases (express checkout and other stuff I don´t even know what it is). That confuses me because I don´t know which values are relevant for my case.
Does anyone know a good and simple tutorial or example of how to handle IPN?
(which goes a little bit further than how to receive the IPN)
The PayPal IPN Variables documentation lists all of the transaction types and the values you would expect from the different types of payments you could be processing. The descriptions next to each should give you the info you need about when you should be looking for one value vs. another.
So you said you're using basic Pay Now button, right? Based on the documentation this would send a web_accept IPN.
Payment received; source is any of the following:
A Direct Credit Card (Pro) transaction
A Buy Now, Donation or Smart Logo for eBay auctions button
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
In my web application (spring mvc + jsp), I have to implement payment process which I will take the money of someone (i.e buyer), deposit to someone else (i.e seller), and keep a portion for myself (i.e commission). I would like the process will perform on my website instead of redirecting to paypal. I have tried to search for the service that I need, but after a while of reading it, I am very confused. I am thinking I may need some mix between Adaptive Payment or Website Payment Pro. However, I think that Paypal would also provide a service that I am searching for, but I haven't found yet. So would anyone mind to help me out of this confusion please?
In order to do the payment split as part of checkout you would need to use Adaptive Payments, specifically the Pay API with a chained payment. Unfortunately, you can't avoid redirecting the user to PayPal with this method.
If that's a must, then you'll need to go with Payments Pro, but then you can't do the split within a single checkout, and you can't split the fees up among the receivers. So you'll end up paying a fee when you receive the money, and then when you send the money there will be another fee there, too. Also, if you go that route you would be responsible for any chargebacks that occur, so this is simply not recommended.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am facing a problem with paypal integration. From my site I want the user to go to PayPal's site after selecting their product. But once the user makes a payment they do not return to my site so their order is not saved in my site but payment id going through to paypal.
I am using php to integrate.
Can anyone help me fix this?
I believe you would need to store the details before sending the user to PayPal to make their payment, so you have a record of 'intent' to purchase goods from your store. That record should contain details of who the customer is, what they are buying, and how much it costs.
Then, your customer is redirected from your site to PayPal to make the payment itself. At this point, they can either click 'cancel' if they change their mind (or just close the window down). Or they can make payment. After making payment, they can and should click the 'Return to site' button to go to your store and its confirmation page. Alternatively, at this point again, they COULD close down the window altogether. Having stored the purchase intent beforehand means you still have access to the data in the transaction.
So the following can happen:
The user presses the 'cancel' button. You can return to your site and remove the database record as this purchase will never be completed. If the customer still has their cart and buys later, a new record will be created.
The user closes down the window before making payment. You still have the database record which can be used later. After a certain period of time, when its assumed that the user isn't feasibly coming back to complete this particular order (a few days? a week?) you can delete the 'intent to purchase' record.
The user makes a payment but does NOT return to your store immediately using the 'return to site' button on PayPal. You still have the transaction details, and PayPal will still trigger your IPN script to verify that the payment went ahead and whether it completed or there were problems. You can compare details such as cart contents and total amount with your 'intent to purchase' record to ensure that everything is valid. You can then move this record to a 'completed purchases' table.
The user makes a payment and returns to your store. You can display a 'thank you / order confirmation' page to your user, tell them they have made a payment. PayPal will trigger your IPN script to that the payment went ahead (or what happened to it). As in the above step, you can compare your IPN information with the intent record to ensure its valid and real.
I believe this takes care of all eventualities, doesn't require an uninterrupted session because you're using a database - so the buyer doesn't have to return to your site following payment. Likewise, you won't have a cluttered up sales table that contains all of the people who were about to check out, but for some reason didn't proceed to make a payment. These records will be in 'intent to purchase' and you can periodically clear out old ones (or analyse the data to find out why people are dropping out of the process).
--
I hope this helps. I'm having the same problem today, and I think by actually having to write this answer out has helped me clarify it better for myself.
Integrating with PayPal is very simple.
I especially enjoy doing this with custom made web pages because it allows complete flexibility, as opposed to working with limited options that certain software provides.
Simply create a PayPal business account, create and code your own website, then click the "Buttons" tab when you log on to your PayPal.
You will then receive an HTML code which you can place wherever you want an "Add to Cart" option or a "Buy Now" option.
From there, customers can easily select items to buy and safely and securely checkout using their credit card.
I hope this helps. I will be happy to reply to any further inquiries.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
What are the options to accept a credit card payment from an iPhone application? This will be a stand alone application, not an iPhone specific web site. Can I integrate with a payment gateway like Authorize.net? What about paypal or Google checkout? I know on some web sites, it will take you to a paypal site for the payment authorization - can this be done over http requests, instead of forcing the user to another website (which won't be available from the app)? Are there any security concerns with these payments from an iPhone as you can't install an SSL certificate?
I don't want to use the Apple micro-payments that will be available in the 3.0 release as there will be many small charges, and I don't want to give 30% to Apple each time.
Is this even possible, or will I need customers to create an account on my web site beforehand, pay with their credit card, and then have the iPhone interact with my database to get their available balance (the amount they charged through the web)?
I think that 30% is well payed...
No need to think about credit card fraud
No need to think about secure certificates
No need to think about server problems like downtimes
No need to thing about creating a nice UI and description of How to use
No credit card needed to buy as the user just need to fill up the iTunes password, so they can buy anywhere, everywhere
No need to spend a lot of time debugging and testing, the SDK is great and works like a charm if you just follow the documentation
And you can always add 5 dollars more to cover the 30% on what are you trying to sell.
Remember that if you have a lower price, you will have much more buyers and you can have much more profit that a few buyers with a higher price.
It's really quite easy to charge money with PayPal. It just depends on what kind of feedback you want from PayPal. See PayPal's Developer site for more info.
EDIT: I really should explain what I mean by "feedback".
When a user is sent to the PayPal site to pay, you can send him there using a fairly simple web-form (yes, a plain <form>...</form>.) If you only have 1 product, then this form can even be static HTML.
The tricky part comes after the user pays.
Option 1: Check you PayPal account manually for the payment. If the user paid, then you e-mail him, and send whatever you wanted to sell him. Easiest method, least amount of code. The downsides are that you'll have to do a lot of manual checking, and basically this is just a drain on your attention.
Option 2: Get automatic confirmation from PayPal in your application. Either by getting post-backs sent to an HTTP server by PayPal, or by actively querying the PayPal server for confirmation after waiting enough time for the transaction to have gone through. This means the user gets immediate feedback once the transaction is complete. You could even automatically send him the product! The downside is that such a solution is a lot more code.
Oh, and every time I said "PayPal"? All the services I just mentioned are provided by every credit-card authorization gateway I've ever seen.