Since PayPal charges transactions but not payment authorizations, I was wondering what is the point of doing credit card validation with Luhn algorithm?
I happen to have trouble with CC validation. If it turns out not to be very important, I could simply get rid of it to solve my problem.
I am not sure I understand your question complete, but PayPal does the validation check to validate the data that is attempted to be passed before it passes it to the processor.
Related
On the Paypal Basic Integration tutorial it is possible to capture an order client-side which essentially submits the payment to paypal. Once the order is captured, the tutorials shows you how to verify the transaction which would ensure you do not provide a service or product unless the paypal order is verified. However, someone could maliciously capture a payment using the client id and while verification would fail paypal would withdraw the funds from the customer. How can you prevent this? Is this secure?
[UPDATE]
This questions comes mostly out of curiosity and lack of experience with paypal. To put more context into this and hopefully help others; the Paypal basic integration is simply an HTML form and so it doesn't stop anyone from modifying the HTML form and send a different amount for authorization/capture; lets say that the original amount for an order is 100, it is possible that someone changes that amount and submit the authorization with the different amount; at the minimum it would initiate an authorization/capture of this different amount that perhaps is higher. Good practice dictates that the amount and orders should be verified before finalizing the transaction on the backend, but even if the transaction is found to be invalid the funds would have already been put on a "hold" by paypal and possibly on the customers credit card.
This is probably not an issue since, like mentioned, transactions should be verified on the backend; it is also not too obvious( maybe with some social engineering) how someone would benefit from this and most likely would just be an inconvenience.
Can some confirm something for me; I've searched PayPal's docs and just can't find the answer.
If calling SetExpressCheckout with the parameter 'TOTALTYPE'= 'EstimatedTotal', how much headroom does PayPal allow for finalizing the transaction?
For example, someone carts an item that has a cost of $1. They click PayPal Express and get sent to PayPal to authorize an estimated amount of $1. Then they return to the merchant site and now that their address is known, the cart says shipping is +$20.
Is that acceptable? I'd really like to understand the groundrules on this, as I don't want to risk any authorization errors due to insufficient order amount when making the request.
Well, I have to answer my own question here. I called PayPal. The answer is "it's handled, don't worry about it". They would rather not publish the details on their proprietary algorithm because there are fraud tests, etc. going on -- but said it is a key design point for them and it is absolutely handled no worries.
If you are not passing a SHIPPINGAMT variable with the SetExpressCheckout call, then we will not display or "calculate" shipping on the PayPal page. When they are transferred to the PayPal page the customer is not authorizing the payment per se, rather they are selecting their payment method/funding source to be used when the DoExpressCheckout call is passed.
Only after the customer is transferred back to your page, and the final order total is known and passed via the DoExpressCheckout is the payment initiated. The difference between the total amount in the Set call and the Do call does not matter. Perhaps the agent with whom you were speaking with under the impression of an authorize/capture structure being in place. This will limit the final capture amount to the authorized amount +/- 20%.
Of course this is all turned on its head if you are passing the USERACTION=COMMIT variable which will "finalize" the payment on the PayPal page, while the DoExpress call is run transparently on your end. This will change the text on the button on the PayPal page to "Pay Now" instead of "Continue: You're almost done. You will confirm your payment on yourwebsitehere.com"
I hope this helps!
I integrated PayPal in my web shop in order to allow instant payments with automatic product delivery (already had this before but only with instant wire transfers via sofort.com). I integrated it with the help of the example provided by PayPal (I'm using ReviewOrder.php, GetExpressCheckoutDetails and DoExpressCheckoutPayment).
It's working great if they pay with PayPal balance or a linked credit card. However, some customers from Germany don't have balance in their accounts but only a bank account linked to their account. The payments go through and they receive their product, however I noticed the payment status would remain "Pending" for 1 month and change to "Expired" afterwards, so effectively no money arrives.
Why is this happening? Or is there any way to deny such payments? (Payments from backup funds)
Any help would be appreciated.
Its hare to day with out looking at the transaction specifically. But there are several things that can cause your payment to be pending, such as your preferences that you may have set in the account. Check to make sure you dont have your preferences set to ask me before accepting a payment in a currency that you do not hold. Did the buyer pay with an eCheck? If so, it could be waiting for the payment to clear. If this is in the sandbox, you have to manually clear the payment. If you are still not able to determine the cause of the pending payment, if you provide the transaction id, I will check it on my end.
Hey guys I managed to find a solution to this odd problem after all.
It turned out I had the following code in my implementation where I actually initialized the payment process:
$_REQUEST['paymentType'] = "Order";
This was a mistake though, since this payment type won't place a hold on the funds and if the DoCapture call is never called this payment will remain pending for about one month and then expire entirely (as described in my question, so this is what actually happened to me). The bad thing is that it's impossible for such payments to even accept them manually from within PayPal (not even the local PayPal phone support was able/wanted to accept these payments for unknown reasons because they told me they'd come up with a solution and contact me via Email within 24 hours but they never did).
So in order to fix this issue I changed the payment type to Sale which instantly captures the payment rather than waiting for sort of approval or a capture call. It worked fine for two weeks now and I think I'll leave it like this now.
$_REQUEST['paymentType'] = "Sale";
I lost about 110€ because this stupidly trivial detail but at least it's working fine now and I was able to re-enable PayPal as a payment form. I hope they'll at least add an option to manually accept these payments if the DoCapture call was not implemented because it worked fine without it for most of the payments as well and after all this is still about real money, so this absolutely would be an essential thing to have....
This can happen also if you are trying to accept a payment in a different currency of your account. To avoid that you must create a "PayPal balance" in the currency of the payment.
IPN is also giving hints on the pending reason in this case:
[pending_reason] => multi_currency
If I set paymenttype to instantonly, is there any reason to set up IPN? Don't I get all the information I need from do_express_checkout?
There will be a bit more information returned in the IPN. The IPN will also update you as well if for some reason PayPal places a hold on the payment, or a charge is filed against the transaction.
What Chad said is right, but practically speaking there's no reason, and the vast majority of EC integrations make no use of IPN.
In my PayPal Pro credit card payment system, I use the Luhn algorithm function given in the first answer to this question. However, I have several US clients who apparently tried to pay with their credit cards and their details were rejected by the function (return false), although my script allows them to try any number of times.
At the same time, I know other clients' CC details were indeed accepted by the function and payments were successful.
I conclude there must be something wrong with the function itself. Is that possible?
To answer your question I'd have to get a look at your function. You didn't include that here for review.
That said, I'm curious why you're messing with that at all..?? If the credit card is invalid the PayPal API will return an error that informs the user of this. Let their system handle it for you. No need to add extra checks of your own.