I have a simple IPN script but users can modify the price of the package in the URL.
An example would be: Package price is $500 but they change it to 1 cent and then pay and
they still become activated. IS there any way to fix this?
Thanks.
You have to check the price in your IPN script, and if it doesn't agree with the database you should reject the transaction. Better still, do nothing, that way you get to keep the money, and let them complain about it.
Related
In production, DoExpressCheckout is returning PayPal error 10422 'The customer must return to PayPal to select new funding sources'.
What docs I've found from PayPal are limited (https://developer.paypal.com/webapps/developer/docs/classic/api/errorcodes/#id09C3F05600A)
Instruct the customer to use a different funding source. Offer the customer a quick link to restart the Express Checkout flow and redirect the customer back to PayPal.
I'm trying to figure out what this means since I personally have no way of regenerating the error and so have no way of testing my code (and asking my exasperated customer to do a couple walkthrus while I sort out the kinks seems unreasonable).
Does anyone know
references for causes of this error?
How to generate this error myself to walkthrough for customer experience?
What redirect should be used? (the first paypal.com...?token= url or should I now be including PayerID?).
All comments solicited.
I believe Paypal is instructing you to start the Express Checkout process over on YOUR site (as in generate a new token).
Yes, their error codes leave much to be desired
There must be something wrong with the funding method the person chose while on the PayPal pages. Maybe they chose to pay with a bank account that isn't verified and your system wont' accept that, for example.
Is this a customer telling you they're getting this error, I'm guessing..? I would ask them what type of payment source they're choosing and see if anything jumps out about what could be wrong.
In our early test/launch of our product we would like to sponsor the $.25 Dwolla charge when a payment above $10 is made. Is there any clean way to do this? Clearly the transactions know the developer account information in order to make facilitator fees possible, but you can't set a negative facilitator fee. I can think of the hacky option of pairing every real transaction above $10 with a $.25 transfer from the developer account, but I am looking for something that will be transparent to users if possible.
There's no clean way to pay the transaction fee as a facilitator, unfortunately. This is an interesting case, and a negative facilitator fee would probably be the best way to solve it. I'll bring up this potential feature with our team!
For now, however, the hacky solution of reimbursing the recipient or sender of $0.25 is the only viable solution.
I am working on a startup in which the merchant has to disburse funds to customers periodically, from time to time. Think of this as customer loyalty program, cashback etc.
Does dwolla support the ability to transfer money from merchant to customer?
Technically it seems the same as from one bank account to another but just wanted to confirm if that is the case. (Is there a refund API that can help with this?)
Also, would something like this be against the terms of use ? Is there a possibility of running into compliance bottle necks?
Appreciate your help in this as this would help me choose dwolla as our payment processor.
Thanks and Best Regards,
I'll let Michael chime as well but the generic answer is yes. You can do that. You'd simply make an outgoing payment from a bank (or dwolla balance) to the receivers e-mail or phone #.
Not against the terms at all. Let us know if you need any guidance during the process.
The scenario you're describing sounds completely legitimate to me. The only caveat I can see here, is the fact you'll have to store the merchant's PIN number in order to periodically send money from their account, without their direct involvement (or am I understanding this wrong?) - our ToS requires that you hash/encrypt said PIN in your DB.
Regarding a refund API - we don't have one yet. You'l have to simply use the send() method, and if you're so inclined, feel free to break the amount to $10 chunk to avoid any fees.
Bottom line: you should be good to go.
I'm having trouble figuring out how to prevent people from editing the amount in my shopping cart with tools such as firebug. How do I make sure users can't edit the hidden field? Can I encode the amount before sending it to paypal?
Thanks!
Francois
Okay, turning comment into answer...
Don't encode the hidden file! When a customer makes a payment, PayPal will handle the transaction and tell your automated system that it has received the payment. It should also tell you how much the customer paid you! You then compare the amount paid with the original invoice and if there's a difference, you just tell the user that the payment is incomplete. (Unless they paid too much, of course.)
As Chris Lively tells you, don't trust the customer! Always check the amount that has been paid. Once you do this, it doesn't matter if the user hacks into any hidden fields, since you check it afterwards.
If your security depends on keeping your users away from hidden fields, your security will fail! Your security should depend on your contact with PayPal directly. Only when PayPal confirms the payment, you should send the product.
I'm sorry to say, but you can not prevent people from fiddling with the html / post variables. One common security mantra is "Don't trust the client".
The process should be to have the client post back to your server. It recomputes the totals or whatever, then send that to paypal. Obviously there should be some sanity checks like preventing zero or negative quantities; however, the client itself should NOT have control of the totals.
I'm trying to integrate a payment mechanism to my site. The scenario that I need is not trivial and can be explained by the following example:
User pays upfront for a subscription program (i.e. receiving Netflix). User is able to make changes to the subscription (i.e. change number of movies checked out each time from 4 to 2)
User is able to buy additional one time purchases via the provider's site (Netflix) supplied by 3rd parties. These items (i.e. popcorn, snacks) get billed to the same credit card as the subscription without having to go through the process of resubmitting the credit card information.
Of course, my site takes also a small fee for the transactions :-)
I was wondering if this is supported by PayPal, Google Checkout or someone else.
Thanks.
The Paypal api can handle all of those processes.
I seem to have dropped the ball on what kind of answer you wanted so I'll leave it at that.
If you have some feedback, more direct questions I will try to answer as much as I can
--
The money would best go through you first, unless somehow you can convince your customers its normal to bill them per item. Also if they pay by credit card you should only bill them once as you would incur fees on every payment. I don't know of anyway to bill once but distribute the payments.
As for the paypal docs..
Very good resource, there is also some sample code for most major web languages
Also this will get you started if you don't have a developer login
Their developer support is also pretty good. One thing a lot of people seem to screw up when starting out with the paypal api is not setting the latest version in the configs so don't forget to update that to the latest release. :)
Disclaimer..
Yea I know there is a lot of bad press about paypal and crazy stuff happening, but they do get the job done most of the time, its not my fault the customers love to use it.