I am creating subscriptions using the PayPal Express Checkout API. What I want to do is add a seller-defined 36 character ID to each subscription that I can later search on.
When sending CreateRecurringPaymentsProfile, I am populating the PROFILEREFERENCE field, which shows up as the 'Invoice Number' on the Recurring Payments dashboard on the seller site.
On the TransactionSearch method, there is an INVMUM field that can be searched, but it doesn't appear this correlates with the 'Invoice Number'.
So...how can I populate the right field so I can use INVNUM to search - or is there a better solution to my problem?
Bruce
I would setup an Instant Payment Notification (IPN) solution. That way any data for transactions will be automatically sent through your script and can be processed accordingly in real-time.
The PROFILEREFERENCE value you're sending will come back in the IPN as invoice_number, so it would be available within your IPN script.
So whatever you're doing within a TransactionSearch script, just do that in IPN instead. Not only will give you access to the value you're after, but it will automate the entire process in real-time so you don't have to mess with TransactionSearch / GetTransactionDetails at all.
Related
I'm overflowed a little bit reading Introducing IPN https://developer.paypal.com/webapps/developer/docs/classic/ipn/integration-guide/IPNIntro/:
at the begiining: "IPN is a message service that PayPal uses to notify you about events, such as: Instant payments, including Express Checkout, ..."
at the end: "If you are using Express Checkout ... You should not use IPN for this purpose."
Perhaps anybody knows correct option - to use or not to use IPN with Expres Checkout?
IPN can be used for purposes such as:
Trigger order fulfillment or enable media downloads
Update a list of customers
Update accounting records
Create specialized "to do" lists
If you are using Express Checkout or Direct Payment, the PayPal API notifies you of the status and details of the transaction immediately and automatically. In either case, you can immediately show your customer the payment information returned by PayPal . You should not use IPN for this purpose.
This means that you need not use IPN for knowing the transaction status , because once "dodirectpayment" is completed, you will know the transaction status immediately.
Yes, if you want to use IPN for backoffice operations such as updating your own database, emailing your customers upon purchase and offers etc. you can use IPN with Express Checkout.
I currently have a simple Paypal button on my website where people enter some information which is saved into a database, and the button then takes them to paypal to pay £20 to join. The problem is there is no link between the website and paypal, so I have to manually cross check who has joined on the website against Paypal each time.
I've looked into Paypal IPN which looks ideal, but I can't work out how to match the transactions up.
i.e. IPN sends me a txn_id, but I don't have that at my end. I need a way to send a generate & save a unique ID per transaction, that goes to Paypal with the user, and Paypal then sends back to me via IPN.
I'm quite lost in Paypals shoddy docs, so any help from SO would help!
(Off topic rant: why to Paypal have so many domains: paypal.com, paypal-business.com, x.com, paypal-marketing.com,... Can they not spell phishing?!)
Pass YOUR id (like the DB row id) to Paypal with custom variable, you can cross reference it using the custom variable from IPN.
https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_html_IPNandPDTVariables
I'm trying to using paypal as payment for my site.
My site only sell a virtual currency, like "Diamond" in Online game.
So after reading i starting to use Express Checkout for Digital Goods, Is that right ? or i must other payment method ?
Then my question is when using Express Checkout for Digital Goods, how to pass custom variable ?
Let say i want to pay user_id, diamond_id, and some other variable from my database to the paypal api. It seem like paypal don't support custom variable to pass on the api call. I want after user complete the payment, then Paypal notify my server that the payment is complete by user_id and some other variable that i pass, so easy for me to know the detail.
after searching i find some solution,
First solution is to store "TOKEN"(Generated from "SetExpressCheckout" Method) and my custom variable which is belong to the TOKEN in the database, Then after payment complete paypal will notify my server the same TOKEN saved before. So i will query based on the TOKEN.
Second Solution is using get style in RETURNURL variable http://www.mysite.com/successpayment.php?user_id=13&diamond_id=88 So i will easy to grab the GET variable.
Which solution is right ? Is there any solution ? and how to secure the payment confirmation, i mean if someone know and hack my returnurl.
Thanks in advance
There are two parts to be able to successfully identify your order in the whole process:
To identify your order when the user is redirected back via the success or cancel URL, just pass the order id via the query string of the URL.
To identify your order when Paypal sends notifications about the transaction and associated events (refunds, reversals, disputes etc.) via IPN: Paypal does support a pass-through variable, which allows you to associate IPNs to the order record in your DB.
For express checkout you set PAYMENTREQUEST_0_INVNUM in the SetExpressCheckout call
In case you are creating a recurring profile, the parameter is named PROFILEREFERENCE in the CreateRecurringPaymentsProfile call
When you receive an IPN the invoice is passed as 'invoice' or 'rp_invoice_id' respectively
(My general advice, though: use Paypal only if you really have to)
I'm setting up a payment engine for a custom framework using PayPal Express Checkout. One of the business requirements is adding support for recurring payments. I've found documentation on how to implement this at https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_api_ECRecurringPayments
The thing I don't quite understand is how to retrieve the value of BillingType from the API after I've set it via SetExpressCheckout to "RecurringPayments". It doesn't seem to appear anywhere in the response data I get back from neither GetExpressCheckoutDetails nor DoExpressCheckoutPayment. I need this to know whether I need to create a recurring payments profile or not. So as far as I can tell my only option is to store the value of BillingType in my database and query it again after DoExpressCheckoutPayment. This works for me but I find it odd that this data would not be returned at all by the API. Am I missing something? Or is there another way of correctly implementing recurring payments?
Not all data you send in a request is returned in a response. You already have what you're passing to them...there's really no need for them to pass it back.
You could use session variables to save the data instead of the database, or you could log all of your API requests and refer to those logs when you need to see what you sent, but again, your application is what's telling PayPal whether or not the payment should include billing agreement information...not the other way around.
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.