I am working on a software service and am offering a monthly subscription for my software service.
I am currently working on the subscription part - and am wanting to implement a paypal monthly recurring payment solution.
I have spent quite a bit of time looking over PayPal documentation, and trying different buttons, webhooks, IPN methods etc.
The problem is that I am not sure what solution to use - because I am confused by the multiple options.
What is most important to me is - that when the customers fill out the form on my website - and are then directed PayPal to pay - I then want to know that specific Customer ID from my website has successfully paid.
I would like to know:
Which SPECIFIC option(s) PayPal has that I can pass Customer ID from my website of that customer - let's say a subscription ID from my site - and that PayPal will then send the customer back with my subscription ID, that I passed them on to PayPal with.
Which is the easiest option to do that with?
I simply want the customer to:
sign up at my site. (my part)
be issued a unique Customer ID from my website (my part)
click a PayPal payment/subscribe button (my part)
be sent to PayPal to pay for the subscription (paypal's part)
be returned to my site with the unique Customer ID from my website from my site - as well as a confirmation of payment from PayPal (paypal's part)
Please do not simply pass me to the general area of the development sections -
As I said - I have already been through all of that and find there is too much information.
Please direct me to a specific solution, or example, or tutorial that covers a solution that will fit what I need.
I would recommend using the Express Checkout API with Recurring Payments.
The best thing to do would be to create a local invoice record in your system, and then have a related customer ID associated with that invoice.
In the CreateRecurringPaymentsProfile request to PayPal you can include a PROFILEREFERENCE parameter, which would be the invoice ID you generated for that order in your system. Then all future payments related to that profile would include this same reference ID as part of its data, so if you're using IPN, for example, it would be included there.
When working with Express Checkout the user is always guaranteed to end up back on your site to finish the checkout flow, so you can simply save data in sessions during checkout and update things like your database, email receipts, etc. directly in your payment flow. Then you could use IPN to process the recurring payments after that, and again, it would include that same reference ID. In IPN this would come back as rp_invoice_id.
Related
I have been manually issuing invoices to charge my clients for services using Paypal.
Now I am creating an interface to allow them to purchase the services automatically on my website.
I also want to show them a history of their purchases. However, I cannot show a history of paid invoices using the Transaction Search API; I need to use the Invoicing > Search Invoices API.
I have used the Paypal Payments API to manage the payment side of new products, which now correctly produces an itemised transaction and allows the customer to checkout. But this does not produce an invoice.
How can I simultaneously produce an invoice (i.e which can be retrieved by the Invoicing API to show previous payments) and allow the customer to pay it? It seems like the Invoicing API works around the idea of sending an invoice to client by email, but this is unnecessary. I want them to pay it immediately (and already have the Payment API setup for this).
So what would a useful workflow be?: Use my Paypal Payment API to receive and authorise the payment, and on authorisation, use the Invoicing API to produce an invoice which reflects this and then updates the invoice status to paid? Or am I missing something easier here?
The Invoicing API is not meant to be mixed or used with any other API. It is for generating invoices to be sent by email or in link form.
General ecommerce payment processing (without invoice links) is entirely separate, there is no crossover. You should ensure you are using the current v2/checkout/orders API to receive new payments, not older v1 APIs.
As far as displaying a list of previous purchases to your customers, you shouldn't reply on PayPal for this (except perhaps in the case of invoices since this is part of the point of offloading invoice management to PayPal). But for normal web purchases, PayPal is not a database -- it is a payment processing service. Keep track of all your own order information, and simply store PayPal transaction IDs when they complete for your own accounting records -- but the ID you reference with the customer should be your own unique order ID, which you can pass to PayPal in your purchase_units[0].invoice_id when you create an order for checkout approval.
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 working on a website to sell some advertisement concept online, where user can get the access of more options after opting a monthly subscription paying through recurring Paypal.
I have already implemented the recurring paypal functionality successfully except one thing. Like One can subscribe for the plan and monthly payments are deducted from the concerned account.
But I have no idea how to update my database after the first payment from the recurring paypal.
eg, a customer comes to the site, choose his options, went to paypal recurring part and made the transaction. Now I have one page , where the paypal returns the control, which is given on the return url. Now the problem is, in this page when I am updating the database, the paymanet status is pending.
Then after a while when the IPN response comes to the application, I wont able to update the earlier entry in my database, as I am not sure how to match these two entries, I mean upon which field the update query should be coded.
There's no point in updating the database at all until you get the money. When you get the money, the transaction contains everything you need to create or update the subscription.
I was wondering, if you have coded a website which uses paypal payments as a payment method (the kind of payments where you get redirected to their site for payment, not web payment pro).
What kind of details can I store? Is it just their paypal email address that can get supplied to me or do other details regarding their paypal account also get sent to me via their API which can be stored on my site?
As already mentioned, you get the details of the transaction, so email address, name, delivery address and the contents of the shopping cart.
You can send custom parameters from your form though, such as phone number.
Paypal, by default doesn't ask users to provide a phone number and therefore usually doesn't send you one. However, it's often useful for retailers to have a customers phone number.
If your shopping cart is populated by your website and then customers are asked to complete a brief, name, phone number, email form before submitting to Paypals site you can send these extra form fields to Paypal and have them come back to your server for storage/checking.
However... I found it very erratic! There seemed to be a problem with my account when I did this and the PP technical team couldn't explain why it was only sometimes working! I gave up in the end and found a Payment gateway with credit card and Paypal integration, now all my payments come through the same channel and callback methods regardless of type.
http://www.securehosting.com I use now.
Mostly only the details pertaining to the transaction can be retrieved in the usual procedure, as it appears even when you see the transaction details in your paypal account when you receive payments. However, it would be helpful for you if you can provide more information on what you wish to look for.
I wanted to use Paypal's IPN service to verify payments for a recurring subscription charge for my website. How do you tie the IPN confirmations to a user in your site?
The IPN confirmation message has a name, email, paypal ID, recurring payment ID, but it seems to not give a unique identifier since I don't know where the paypal ID or recurring payment id comes from and it may not be trivial to uniquely match up the name/email that a user has on their paypal account (or entered there) with the name/email I have for them on my site (there may be many John Smith's and the person may choose to use a different email.)
1) When I send the initial payment request to Paypal, I can attach a unique UUID in the URL I ask them to send back to me, so if I save that unique ID for that user I can match that payment confirmation to the user who initiated it. Am I making that harder than it is? Is there an easier way?
2) Also, for a recurring/subscription charge, does paypal always use the URL I specified with the initial payment initiation? Does anyone have practical experience using the recurring Paypal payments with IPN's, does it reuse that unique URL? Or do I have to associate the Paypal ID's with the user after the first recurring payment is received?
Attaching unique data to the payment request is pretty much the accepted way to do it.
I don't have any experience with recurring charges.
I recently also set up some reoccurring payments with Paypal.
I actually wanted people to register as members after paying for the subscription, if they wanted to. As having to sign up as a member could add some friction to the sale process. So I don't send any user info along with the Subscribe button.
What my IPN script does is generate a unique activation code tied to the Paypal subscriptionID in the Activations table, then it sends this code to whoever paid for the subscription, with instructions on how to activate.
At the point of activation, you need to register or login. At this point the userID is added to the relevant row in the Activations table.
When the EndOfTerm IPN notification comes in the IPN script looks up the userID from the Activations table based on the SubscriberID given in the IPN. Then I can do whatever I need to do to that user to disable their subscription.
At all time the URL of the IPN script remains the same.
1) You can send an 'item_number' parameter with the initial subscription setup, which will get passed back to you. I'd suggest embedding an identification token in it.
2) If you mean the 'return' parameter, no, that's for sending the user to at the conclusion of the subscription setup. The renewal is automatic and doesn't 'ping' that page.
1) You want to be using the item_number parameter. Set this in your HTML form shown to the customer, and it will be returned to you by the paypal IPN, so you can put a database row ID in here, and use it to match up to the right person later.