PayPal v5.4.2 - not passing on address

[smarterweb]

Not sure if this is country related (there used to be different official PS paypal modules for uk and usa) but in this latest version, address details do no longer get passed on to the paypal website when using PP standard method.

We're based in New Zealand and used to have to install the UK version.

[lesley]

I am not sure anything should be passed other than the total of the transaction. 

[smarterweb]

in the official PS paypal module all that information is passed on to paypal, so users don't have to fill out another form with the exact same details (address).

[Guest]

I am not sure about the technical side of this but I will say:
This module used to report transaction information to PayPal.
In recent updates, it does not. I just get the order total amount.
By transaction information, I mean, the actual order details. (the items which are in the order)
I am not sure about the address itself. I haven't noticed that in particular.

I am not sure which way it is technically supposed to be, and either way, this does not bother me at all, but it definitely used to show up.
I have proof of this in my PayPal history.

Edited March 11, 2019 by Purity

[SLiCK_303]

15 hours ago, Purity said:

I am not sure about the technical side of this but I will say:
This module used to report transaction information to PayPal.
In recent updates, it does not. I just get the order total amount.
By transaction information, I mean, the actual order details. (the items which are in the order)
I am not sure about the address itself. I haven't noticed that in particular.

I am not sure which way it is technically supposed to be, and either way, this does not bother me at all, but it definitely used to show up.
I have proof of this in my PayPal history.

I have noticed this as well...... That the Order Details are no longer showing up in Paypal, which for me sucks.... ;(

[lesley]

I removed it to make the module more stable, because the paypal api sucks to be frank. 

[Guest]

9 hours ago, lesley said:

I removed it to make the module more stable, because the paypal api sucks to be frank. 

You're not the first person I've heard say that about their API. lol

[datakick]

Every piece of data thirtybees send to paypal is subject to very strict validation, even if it's optional. When it fails to validate for some reason (wrong postcode, country code, different rounding), then the whole transaction is rejected. This was one of the reason why old versions of paypal module did not work for some merchants.

The solution for this problem was to send only required information, and scratch everything optional. It is not the best solution, but it's the simplest and it just works.

[lesley]

To illustrate @datakick's point even more, these are some of the scenarios that we were facing. 

 

For some reason paypal requires states to specific countries depending on where the paypal account is located. So like me being in America, I might be able to have people order from japan fine. But a shop in Germany might require japanese states (prefectures) to be passed in the address. This makes things extremely complicated since there is no published list we could find. So the easiest thing to do was to remove the address from being sent. Its better to not get an address than to have transactions not work. 

 

As for the line items, paypal is the only gateway I have seen that actually uses math on the line items. 

Here is a scenario I was seeing happen. If you have a $10 product on sale for 33% off, the price is 6.666666~ So we would just round that to 6.67 and that would be the end of it. What happens if someone buys 3 of those products? What should the price be? Should the price be 20.00? Or 20.01? Paypal applies their own rounding, which is different than the merchant rounding. When that happens and the price if off, it gets kicked out on paypals side as an invalid transaction. There is not chance to actually pass the amount to paypal and adjust it when it comes back to the shop, its just a hard "This transaction cannot be processed" error when the user goes to the paypal site. 

 

So those are the reasons we removed the data, since removing it there has not been one transaction related bug post / issue either. 

[toplakd]

So does this mean that customer can order to different address compared to the address customer has in paypal?

 

[lesley]

Yes, what ever address they put in the shop will be the address.

[toplakd]

So if paypal claim is opened (for whatever reasons) this might lead to 100% lost case because it was not shipped to the address that is registered with paypal, if customer entered different address in shop.

[lesley]

That address is only enforced with the express checkout method. The express checkout method is not something that should be used really, it has very limited use cases. 

[haylau]

1 hour ago, lesley said:

Here is a scenario I was seeing happen. If you have a $10 product on sale for 33% off, the price is 6.666666~ So we would just round that to 6.67 and that would be the end of it. What happens if someone buys 3 of those products? What should the price be? Should the price be 20.00? Or 20.01? Paypal applies their own rounding, which is different than the merchant rounding. When that happens and the price if off, it gets kicked out on paypals side as an invalid transaction. There is not chance to actually pass the amount to paypal and adjust it when it comes back to the shop, its just a hard "This transaction cannot be processed" error when the user goes to the paypal site. 

 

We see this happening quite often using the PS paypal module - and it is really annoying!

Shame we have not been able to get the TB module to work, but I agree with everything @lesley and @datakick have said. Keep it simple to allow PayPal to work