I need to track user payments on my site, but there is nothing in an IPN that I have been able to link to my original payment.
Some people suggested using the "custom" field (http://stackoverflow.com/questions/11251109/paypal-button-sending-custom-variable-through-ipn), but that doesn't seem to be an option through the Adaptive Payments API.
So are there any fields I can attach to my Pay API call or my SetPaymentOptions API call that will a) be invisible to the user, and b) come back in the IPN so I can track the payment?
My only other options are to either track with the paykey (but that seems wrong since it is public and expires and a given transaction can have several paykeys), or to send the ipn notification to a tracked url such as www.example.com/payments/ipn/{transaction_id}
I'm just fairly shocked if there's no legitimate way for me to track a payment.
I think this could be of use to you:
https://www.x.com/developers/paypal/forums/mobile/how-fetch-invoice-data-using-adaptive-payments-api
Related
I new to paypal integration in asp.net . I found very difficult to understand the paypal api .
I under stood two types -
inline html form ( i.e is also called buy button )
payflow api
my questions are :
which one must be used for recurring payment ( subcription packages for end user)?
in first type , few sites suggested to use IPN for confirmation of payment. I want to know is it neccessary since without using IPN, also using notify_url we can confirm the payment success (as per my knowledge notify_url returns to your site when payment is completed at paypal site)?
for recurring payment , do i need to store user account details (i.e credt card or paypal account ) in my databas?
please do reply with you suggestion .
Thanks
1) You can do it with both, actually. If you want to stick with basic HTML forms then you'd be using Payments Standard, and they call it "Subscriptions". You can easily create a Subscription button from within your PayPal account.
If you're using the API then they call it Recurring Payments (or Recurring Billing). You would use Express Checkout for the PayPal signups, and Payments Pro if you want to handle credit cards directly on your site without any redirect to PayPal.
IPN is useful regardless of what integration method you're using, however, don't get it confused with PDT. PDT sends data back to your site's thank you page, or whatever final page you setup for it, and it only works with Payments Standard. When PDT is configured on Payments Standard, even with Auto-Return enabled, there is no guarantee the user will make it back to your return URL. IPN is very similar, but data will always be POSTed to your IPN listener regardless of whether or not the user makes it back to your site.
You'll also want to use IPN to handle updates for future payments on a subscription / recurring profile. For example, the actual payments, cancelations, suspensions, reactivations, etc.
The notify_url parameter you mentioned is used for IPN. Again, though, this is separate from PDT. A common mistake I've seen many times is when people have their PDT and IPN both set to the same URL. Then when people do make it back to your thank you page, the code actually runs twice. Once from the user actually hitting it, and once again from PayPal's IPN server hitting it. So make sure to avoid that sort of thing.
3) No, you will never save credit card details to your server. The subscription / recurring system handles that using the data that PayPal saves on their servers.
Using the PayPal permissions API can you receive notifications from payments made after a customer clicks on a payment button, proceeds to PayPal, and then pays?
I notice they have IPN, but will this work with the permissions API?
Thanks!
You can include NotifyURL in your API requests to set a URL for IPN to POST data to. It's not something that technically "works with the permissions API" but any transaction that is made would indeed trigger the IPN.
If you're building an app for 3rd parties to use, though, and you're passing NotifyURL in your API requests, that will override any IPN configuration each individual merchant using your tool might have setup on their own. This can cause frustration for such users because then their own IPN solution doesn't get hit when they take payments through your app.
If you're going to do that I recommend setting up a way for your users to enter their own IPN URL in your app settings, and then if they have a value, forward the POSTed data to their URL when PayPal sends it to yours. That way both IPN scripts will get hit and process the data accordingly.
I have a form where a team signs up their players and then are transported to paypal to make a registration payment then I receive an IPN when everything is complete. I am doing a similar form and found that Paypal has changed a lot since I created that form.
Is there still a simple way to transfer to paypal, user pays, send back to success page?
It seems like now I have to send the user to paypal using SetExpressCheckout then Getting Payer Details Using GetExpressCheckoutDetails and then DoExpressCheckoutPayment. Am I making it too complicated? It seems I'll be bouncing a registrant around to a bunch of unnecessary pages just to get a payment for a single item. What is the simplest way to do this and still get an ipn to insert into my db? Thanks!
Well EC is the preferred option because its easier for the merchant, but you can use PayPal Standard as well. PayPal standard can be implemented simply as a button. Its pretty simple, but it does not use API calls; its just simply form data posted to PayPal, then PayPal sends you the confirmation of payment in the form of an IPN. the customer is not "forced" back to your site either.
https://www.x.com/developers/paypal/products/paypal-payments-standard
As recommended by PayPal I am using a combination of the PayPal API and the IPN to create a 'Adaptive Payments' flow.
When my IPN listener receives a new notification from PayPal I have two options (after security checks):
1) Use the received data to make direct actions in my website (for example set a preapproval as approved)
or instead a more secure and clean way (I think):
2) Detect the transaction type variable (or other identifier) and request more details from PayPal accordingly.
For example if the 'transaction_type' is 'Adaptive Payment Preapproval' then I will use the received 'preapproval_key' to request the preapproval details using the PreapprovalDetails API call and then use the received data of that call to set the preapproval as approved.
Is this (option 2) the better way to go?
Thanks.
In general there is probably enough information in the IPN for you to act on, but IPNs are pretty confusing what with all the optional fields and the way that there is no payment_status or txn_id on subscribe events, and no subscription information on payment events, so marrying them up can be interesting. You may well find it easier to understand if you go ahead and get the relevant information from them for each IPN via their API as you suggest.
My website allows user to buy stuffs, and the payments will be splitted between a few people (generally 1/4 people).
So far, the processus I use is to receive the payment into one account, and then use the Paypal Adaptive Payment API to send this received payment to all the people, based on their percentage.
The problem with this solution is that the "reception paypal account" will have a lot of input/output money and will be the Achille's talon of my e-commerce (if this account is suspended, my commerce is down).
My question is quite simple: is there a way to do this automatically?
I found that if the buyer have a Paypal account, then I could directly use the Paypal API to dispatch it's payment (based on his paypal email) to the people, and that is perfect, but the problem is : what happens if the buyer doesn't have a paypal account and want to pay with, say, a credit card?
Thanks for your help!
Ok, the solution is quite simple in fact but need a complete change :
I had to forget about Web checkout and use Paypal API, do a PAY request with a Chained Payment (defining multiple receivers, with one (me) setted at primary: true). In that request, set the ipnNotificationUrl to be notified of the evolution of payments and that's it!
The response from paypal, if correct, will contain a paykey.
Then, you have to redirect the buyer to :
https://www.paypal.com/webscr?cmd=_ap-payment&paykey={PAYKEY_HERE}
or
https://www.sandbox.paypal.com/webscr?cmd=_ap-payment&paykey={PAYKEY_HERE}
Then, to be kept updated, all you have to do is send a request to Paypal containing the paykey to know the paymentdetails !
That's it !
I'll answer my question on that, looking into the Paypal Adaptive Payment API, we can see a dedicated section "Guest Payments".
It seems it's possible, but it requires all the people that will receive the money to have a Business Account or Premium account!
Well I'll add a second answer because it's more complete and slightly different from the first one.
The best way to do it quite simply is to use the Express Checkout API (SetExpressCheckout, GetExpressCheckoutDetails, DoExpressCheckoutPayment).
By using it instead of the basic "checkout" bouton with an IPN behind, it is possible to define more than one recipient that will receive the money : the parallel payment.
It's that easy!
(Now I have to rewrite all my code to implement it, yayh!)