Send itemized shopping cart to PayPal WPS

following

I've run into the same issue, and can't find any configuration options for that. My workaround in the meantime is to have the client check the orders page in Drupal or that info, bu it'd be ideal to have it in Paypal as well.

Commerce does not currently do this. If any one wants to make a patch, see https://www.paypal.com/cgi-bin/webscr?cmd=_pdn_xclick_prepopulate_outside for a discussion of how to prepopulate fields in paypal from an external form.

The approach to add this functionality would be to translate customer billing values into hidden fields on commerce_paypal_wps_order_form()

Hello all,

I have created a patch for allowing the contents of the cart to be sent to Paypal.
In your PayPal WPS settings within rules, you must enable the setting and save it.
You can switch back to the overview later if needed by changing the setting to 'No'.

Furthermore, i have included a calculation for the price, which doesn't seem the best way to me. if anyone can improve upon it, please do.

This patch is not compatible with Commerce options but I will look into it if it is requested.

Cheers,
Amarjit

Sorry, attached with corrected filenames at line 1-2

Amarjit

Thanks for all the hard work Amarjit.

I have now rerolled the patch (hopefully) so that it can be applied from the module's main directory as well as the line endings.

This time without the whitespace errors.

I noticed that too and started taking a look at it.

Got a bit stuck on how to bring in the shipping line item to the total to send to Paypal though, so hoping that Amarjit is happy to step up to the mark again...

Having had a load of help from instanceofjamie, I've added in the shipping line item.

Please note that this only brings in the first shipping line item in the order. If necessary, I guess we could just build an array of shipping line items, run through them and send a total.

I'm not sure if Paypal accepts multiple shipping line items or not. Must investigate.

Let me know!

hi, i own this site www.teetron.com and i hav my product priced in indian currency but when sumone tries to buy the wps paypal gate way shows the total payment in "$" unit which meks the price many times higher!! how can i change gateway currency in indian rupee? i tried cheking the setings but it shows very few currency codes.. rupee not dere. help plz..

Thanks so much for this patch Amarjit, shonk and instanceofjamie!

It works like a charm and gets me 90% of the way there for a project that requires this ability. The other 10% includes a custom size field on the commerce product that I use as a product attribute. Could product options be added to this patch? Any assistance would be much appreciated.

Many thanks for the patch, I was just wondering whether or not you were working on passing the Customer name / shipping details also? (it would be a massive help if that's possible)

Cheers

I'm currently trying to get this to play nicely with http://drupal.org/project/commerce_coupon and will try and post a patch when it's working ok.

The patches mainly (at the moment) tick all the boxes I need for my use case, so I hope that they're ok for everyone else as well.

I'm hoping to expand them at some point to cover more bases, but this will have to follow.

@gumpo, not sure about Name and Shipping. Will see how I get on with these other ones...

No problem, we'll maybe take a look at it and submit a patch on completion, just didn't want to be duplicating something if it already existed! Thanks again :)

Can someone send me a copy of the patched version so I can add it to my hosting account (GoDaddy)? I don't have 'patch' on my desktop and it would be easier this way.

Thanks
Matt

Hello all,

I have created another patch containing all the above and then some.

• I have modified shonk's shipping cost to add all shipping costs to 1 amount. Paypal does not allow multiple shipping costs - thus 1 amount for all will suffice.
• I have added a snippet of code to send the 'Billing Address' to Paypal so it can autofill the details. In the event no billing address is available, the 'Delivery Address' is used instead. Otherwise, no address information is sent at all.
• Provided a fix for 0 priced line items.

This is a separate issue but Paypal cannot handle 0 priced line items.
Say you have a 0 priced line item in the middle of your cart; Paypal will loop through each one adding it to the total.
When it gets to the 0 priced, it simply stops looping through the items.

e.g.

Product 1 - £1
Product 2 - £1
Product 3 - £0 (FREE GIFT)
Product 4 - £1
Product 5 - £1

Paypal will set the total to £2 instead of £4.

The only way to overcome this is to not send the free item to Paypal. I have seen this issue for years and Paypal will NOT allow 0 priced items.
The fix will not send the free items to Paypal but will still appear in the Commerce order.

I suppose some of this would need to be implemented in WPP. A quick glance shows that the billing information is sent. Not sure why each field has been limited to x amount of characters (security?).

Anyway, hope this helps.
Amarjit

@Amarjit The patch above did not apply to the clean dev release.

With the patch applied, taxes are not being sent. Help please.

subscribe

Amend to patch #18

New patch which shows the Product title instead.

Hello bmx269,

Please supply more information about your setup and what isn't working.
Do you mean tax on products? on whole order? on shipping?

Cheers,
Amarjit

bolind - You can now follow issues by using the 'Follow' button near the top right.

The tax information that is on the order. So if you had 1 or multiple items in checkout that totalled $100 but after taxes it was $112, the order would pass only $100 to PayPal and on commerce leave a $12 balance owing. The payment does not include the taxes from the checkout at all.

Thanks for posting this Amarjit! With apologies for the newbie question ...could you please post the required location for the patch? I have placed the patch in various spots and each time I attempt to apply it I get something like the following (including the patch command):

$ patch --dry-run commerce_paypal_wps.module commerce_paypal_wps.module-20120223_0.patch
patching file commerce_paypal_wps.module
Hunk #1 FAILED at 326.
Hunk #2 FAILED at 373.
2 out of 2 hunks FAILED -- saving rejects to file commerce_paypal_wps.module.rej

This occurs regardless of location of the patch file. I have tried placing it in /sites/all/modules; /sites/all/modules/commerce_paypal; and /sites/all/modules/commerce_paypal/modules/wps/, with similar results each time.

I am having the same problem as #26 - having trouble figuring out which patches to apply. I am also pretty new to contributing, but if someone can help me understand which ones to apply, I don't mind testing the patches.

Thanks for posting, Amarjit.

I'm having same problem as #26 applying the patch.

Hunk #1 FAILED at 326.
Hunk #2 FAILED at 373.
2 out of 2 hunks FAILED

Keeps failing with the newest dev release.

Any ideas?

Sorry for the late reply.

bmx269 - I will need to look into this.

I will look into creating a new patch that works with latest dev release.
Please note the release number in the issue.

Cheers,
Amarjit

In response to the patch not being applied cleanly, please try the one attached.

Sorry, attached again.

I need to stop editing patches directly after creating them :-)

---
In response to the patch not being applied cleanly, please try the one attached.

Hunk #4 Failed at 218 for me (others successful)

Edit - looks to be because the apostrophe was already formatted how it is supposed to be.

Edit #2 - Once I put the billing address to use first and last name fields it works fully passing details, and the price is correctly calculated. Many thanks for this improvement to the module. Only thing not working is the product name is not being passed - still says "Order n at site".

Patch won't apply form commerce_paypal directory. Patch uses / 100 instead of commerce_currency_amount_to_decimal.

Here's an updated patch to provide this functionality.

Also.. I removed the address info from this patch since there is a seperate issue for that. #1494586: Add the option to collect a shipping address at PayPal

attach is an updated version of the patch from #34 that applies cleanly to the latest dev.

Thanks for rerolling it. Reviewing it today, I'm not sure it's sufficient. There are potentially other types of line items that wouldn't be represented (certain types of discounts, for example, like $10 off the order total) and I don't see taxes included at all. This means the order total would be different from the sum of items passed to PayPal, which would result in the customer being charged an incorrect amount.

I applied patch from #36, but I still need to upload to the PayPal tax_cart variable to specify a tax amount that applies to the entire transaction.
I'm looking for a solution whole day, but still can't figure out how can I obtain total tax amount, applied to the line items? VAT is the one I'm interested in.
I tried

$tax_cart = $wrapper->commerce_order_total->data->components[1]->price->amount->value();

in the commerce_paypal_wps.module, but this didn't work.
Need an advice.

Yep, I mentioned taxes in my comment above yours. To find the total amount of tax, you're going to have to look at the tax price components in the order total price field's data array. We don't have an API function to return the total amount of tax collected in the Tax module, but it's not a bad idea.

I cannot get #36 to apply. Is there any update on this?

Subscribe for #12.

Would be great display product attributes as well together with title.

Hi Guys,

I've attached patch to 7.x-1.0-rc1 version which allow send itemized order with commerce options, billing / shipping address and user info. Just tested - works great for me.

Only one issue I've faced is how to remove html after drupal_render call. I've done it follow way:

check_markup(drupal_render($option_view), 'crop_html');

So you have to create new text filter which remove all html tags (you can do it here admin/config/content/formats). And enable there 2 filters

Correct faulty and chopped off HTML
Limit allowed HTML tags (set allow 0 html tags)

It will clean up html string. But maybe there is another solution for D7 how to render drupal array in plait text - pls suggest!

BR,
Vadim

Also.. I removed the address info from this patch since there is a seperate issue for that. #1494586: Add the option to collect a shipping address at PayPal

#35 @andyg5000 - I think you may be mistaken on this one, the patch you link allows Paypal to collect shipping addresses seperately to Drupal, this patch used to include functionality to pass a person's address details from Drupal to the form, so the customer doesn't have to fill it out twice: If I am mistaken or this is now somewhere else please advise (code from Amarjit's last patch)

+ // Pass billing information to Paypal.
+ $paypal_address = '';
+ if ($wrapper->commerce_customer_billing->commerce_customer_address->value()) {
+ $paypal_address = $wrapper->commerce_customer_billing->commerce_customer_address->value();
+ }
+ elseif ($wrapper->commerce_customer_shipping->commerce_customer_address->value()) {
+ $paypal_address = $wrapper->commerce_customer_shipping->commerce_customer_address->value();
+ }
+
+ // Set address in Paypal data array.
+ if (is_array($paypal_address)) {
+ $data['first_name'] = $paypal_address['first_name'];
+ $data['last_name '] = $paypal_address['last_name'];
+ $data['address1'] = $paypal_address['thoroughfare'];
+ $data['address2'] = $paypal_address['premise'];
+ $data['city'] = $paypal_address['locality'];
+ $data['state'] = $paypal_address['administrative_area'];
+ $data['zip'] = $paypal_address['postal_code'];
+ $data['country'] = $paypal_address['country'];
+ $data['email'] = $wrapper->mail->value();
+ }
+

The patch doesn't work if you don't collect a billing address in the first place. We let PayPal handle that, since we have no need to store billing or shipping addresses at present. Additionally, why would you use the shipping address as a billing address? If an address is intended to be used as a billing address, it should be in the billing address. And unless the customer has indicated the shipping address is the billing address, the system should not assume that to be the case.

The patch in #42 worked for me except I got a php error if the customer only entered one word in the 'Full Name' field of the Billing Section on the checkout page which caused an undefined variable when the $names variable is exploded. The error prevented billing information from being transferred to PayPal. The following is the applicable code from the patch:

+ // Set address in Paypal data array.
+ if (is_array($paypal_address)) {
+ if (!$paypal_address['first_name'] && !$paypal_address['last_name']) {
+ $names = explode(' ', $paypal_address['name_line']);
+ $paypal_address['first_name'] = $names[0];
+ $paypal_address['last_name'] = $names[1];
+ }

If only one word gets inputted in the 'Full Name' field, the last name variable, $names[1] doesn't get defined. I modified the last line in the above code with an isset function:

If (isset($names[1])) {
$paypal_address['last_name'] = $names[1];
}

That fixed the error. Personally I think the full name field should be broken out between first and last name so the billing information remains in sync between paypal and drupal.

I managed to sent taxes in one block to paypal:

$mytax = $order->commerce_order_total['und'][0]['data']['components'];
     	
	foreach ($mytax as $lineitemtax){
		if($lineitemtax['price']['data']['tax_rate']){
			$taxes += intval($lineitemtax['price']['amount']);
		}
	}
    
    $taxes = commerce_currency_amount_to_decimal($taxes, $line_item_wrapper->commerce_unit_price->currency_code->value());
    
    if ($taxes != 0) {
      $data['tax_1'] = $taxes;
    }

I'm not sure how the above works, as it doesn't seem to jive with the Drupal Commerce or PayPal docs. It may function for that particular scenario, however the tax_1 variable is for the tax on the first item, not tax on the entire order. The same applies to shipping.

For PayPal Payments Standard (the new name for WPS), itemized orders must also itemize taxes and shipping charges using tax_x variables for each item. Shipping charges can also be itemized using shipping_x variables, but they only work if the merchant has at least one shipping method enabled in the PayPal account. Instead of the above examples, to add taxes or shipping charges to an itemized order, you should loop over each line item and assign the appropriate amount to the tax_x or shipping_x variables.

Also, comment on #35, #42, and #43: The address that the merchant can provide to PayPal is a billing address, not a shipping address. PayPal obtains the shipping address from the buyer. In fact, there are no variables for a merchant to provide a shipping address to PayPal. The merchant can, however, obtain the shipping address from the PayPal IPN.

I've had some time to look at this myself, and I've attached a patch that should be a bit more functional (and follow PayPal's developer documentation more closely).

- Itemized carts still use the _cart cmd, but summary carts now use the _xclick cmd.
- For itemized carts, taxes are properly itemized rather than lumped into the first line-item.
- Fixed an issue trying to pass a billing address when it wasn't collected to begin with.
- Removed code that tried passing off a shipping address as a billing address.

Shipping costs are itemized for each line item of type `shipping`, but this is still incorrect. For itemized carts, shipping charges should be included with the item to which the charge applies. I'm not aware of a standard way to do that in Commerce, and it doesn't appear that commerce_shipping does it this way. As I don't do use commerce_shipping myself, I'm unable to test this. If someone else doesn't test it soon, I'll install it on my dev image and play around with it.

Just adding here that the Express Checkout / Payflow modules in the 2.x branch can serve as examples for proper order itemization. I haven't looked at the patch in this issue.

I've reviewed the itemization functions in the 2.x branch. The patch will need to be updated to use commerce_tax_total_amount instead. I also noticed that the ec module itemizes shipping charges on a single line, which still deviates from the PayPal docs. That may just be a limitation of commerce_shipping. I do see some other changes that may still be needed and can have an update in the next day or so.

The Express Checkout implementation is exactly as the PayPal docs indicate - one freight amount per payment request:

https://www.x.com/developers/paypal/documentation-tools/api/setexpressch...

See the docs there for the PAYMENTREQUEST_n_SHIPPINGAMT parameter. This differs per PayPal product, but also note that the Shipping module by default only supports one shipping line item through the checkout process anyways.

Sorry; you're right. I was mixing specs. I tested the included patch on a PayPal sandbox with orders including both shipping charges and taxes, and it seems to work. I had to remove code that scrubbed out data that was empty or 0 since an amount is required to get shipping charges to show up. PPS doesn't seem to mind when amount is 0, only when it's missing or truly empty. Taking queues from the 2.x ec module, summarized carts now show a breakdown of taxes and shipping as well.

Just a note: discovered on a call with PayPal today that we don't need to itemize tax amounts - so let's not include those in the line item details for any itemize orders. We can just wait and send the total tax amount with no worries and no rounding errors. : )

I couldn't understand how there would be rounding errors until I saw your comment on the EC issue I created. I've modified the patch to pass an aggregate amount of tax regardless of whether we send a summary order or an itemized cart.

This patch also fixes the case where no tax or shipping variable was passed, which would allow PayPal to add charges if profile-based shipping or taxes were enabled. I think this would be best, unless someone can find a good reason to allow PayPal to request what to Commerce would be an overpayment.

Previous patch was missing round() for quantity.

The patch at #56 worked fine for me regarding itemizing cart content on PayPal checkout page, but after applying it I've lost the taxes. Similar to the description at #25.
I've dumped the $form sent to PayPal and the taxes value is there, like:

  ["tax_cart"]=>
  array(2) {
    ["#type"]=>
    string(6) "hidden"
    ["#value"]=>
    float(9.1995)
  }

According to latest PayPal WPS docs the variable name is tax_cart. Please advice on what can be going wrong. Thank you,

UPDATE: I found PayPal was rejecting the tax_cart value because it was expecting exactly two decimal places. Function commerce_currency_amount_to_decimal() wasn't being loaded because I wasn't using latest commerce version. After updating and getting the value as string('9.20') the taxes showed up at PayPal itemized cart.

#56 worked beautifully for me. Thanks!

(Just FYI) - I'm getting this warning on the Off-Site Payment Redirect page...it still sends me to PayPal OK, so probably just some code housekeeping...I'll just CSS display:none the error block on that page for tidyness.... "Undefined offset: 1 in commerce_paypal_wps_order_form() (line 438 of /home/idexms5/public_html/mytestsite/sites/all/modules/commerce_paypal/modules/wps/commerce_paypal_wps.module).

Also, I had posted (and deleted above) that my customers were being forced to create a PayPal account. Turns out there was a typo in the "Business" e-mail address which was causing this. Once I'd fixed that, I was able to do the checkout as a guest w/o problems.

Using the patch from #56 I found that the approach of moving the shipping line item amounts from amount_x variables into shipping_x variables was leaving the shipping line items listed with $0 values, which looked a bit clunky. I think the shipping_x variables are really just meant to be used where line items HAVE shipping costs rather than our scenario where some line items ARE shipping costs.

The attached patch treats shipping costs more like how the tax costs supplies to paypal, it uses the handling_cart variable rather than shipping_x to inform paypal of the total shipping cost for the order but leaves normal line items itemized.

#60 worked for me after a few hitches.
I didn't realise there were extra itemisation options added to the payment rule form at first and until you've updated it you get a 'cart_type' index missing error on payment.
Line 478 in commerce_paypal_wps.module caused an error as the existence of $wrapper->commerce_customer_billing wasn't checked. I fixed locally this but I'm not familiar with creating patches.

cheers

Hi, @#61 how did you fix this please?
Greetings, Martijn

Go to Configuration » Workflow » Rules and click to edit reaction rule "PayPal WPS"
then click to edit "Enable payment method: PayPal WPS"
and make sure you make a selection under "Select the cart options" before saving

Anyway to port to version 2.x

There is a new version of Commerce PayPal available (7.x-2.2).

I downloaded the zip file and looked at the commerce_paypal_wps module.

It is significantly different from the original commerce_paypal_wps module (the un-patched one that came with the old version).

Consequently, if I upgrade to the new version of Commerce PayPal, it will overwrite the commerce_paypal_wps module, and I am not able to figure out how to patch the new version of the module using the old version of the patch as a guide.

Can one of you more guru-type coders please supply a patch for the new version of commerce_paypal_wps module?

All three modules (original, patched original, new) are in the attached zip file.

Thanks!

- Jeff

Thanks for the update, wasn't sure what patches may need to be re-rolled. Updating this issue's details.

Is a new patch going to be released, or should I find some other route for resolving this?

Thanks.

@jgilberAZ
Here is the paypal WPS patch for the PayPal 7.x-2.2 Version.
I ported the patch from @drasgardian #60.
You have to deactivate/reset the PayPal rule, uninstall PayPal module (Tab "Uninstall" on module page) completely and clear caches - and then install patched version.

Could this be included in the module rather than having to install a patch. There appears to be great interest in it. I'm interested too.

Please confirm this procedure will work:

- Download Patch to /sites/all/modules/commerce_paypal

- Go to Configuration->Workflow->Rules, and disable/reset the WPS rule

- Go to Reports->Available Updates->Update, and update the Commerce PayPal module to 7.x-2.2

- Patch the 7.x-2.2 module
cd /sites/all/modules/commerce_paypal
patch -p1 < itemized-cart-port-7.x-2.x-1301570-65.patch

- Clear all caches

- Go to Configuration->Workflow->Rules, and edit the WPS rule
Edit "Enable payment method: PayPal WPS"
Make a selection under "Select the cart options"

I don't understand why it's necessary to remove the PayPal module altogether.

Ugh.

I finally updated and patched 7.x-2.2 last week.

Then today, 7.x-2.3 comes out.

Can the itemized invoice option please be rolled into the standard module so that we don't have to keep patching it every time it gets updated?

I "diffed" the two modules. This is the only difference between them.

22a23,28
> 
>     // Because the order form generation code does not have access to a payment
>     // method info array, we set the bn directly there instead of making use of
>     // this buttonsource variable. It's here for consistency with other payment
>     // methods in this package.
>     'buttonsource' => 'CommerceGuys_Cart_PPS',
192a199,201
> 
>     // Include the application indicator
>     'bn' => $payment_method['buttonsource'],
421a431,433
>     // The application generating the API request
>     'bn' => 'CommerceGuys_Cart_PPS',
> 

Given that, then I believe the following is possible:
- save a copy of the patched 7.x-2.2 commerce_paypal wps module
- edit the saved copy, manually adding the 7.x.2-3 code identified by the diff, above
- update to the 7.x-2.3 commerce_paypal module
- replace the 7.x-2.3 commerce_paypal wps module with the patched and edited 7.x-2.2 version
- flush caches

I have edited the patched version already, which (I believe) makes it compliant with the 7.x-2.3 version of commerce_paypal. I will go ahead and upload it now.

Can someone verify for me that my assumptions and edits are correct?

Thanks.

@jgilberAZ:

I replaced my commerce_paypal_wps.module with the patched one in #73 and it wokrs.
I wonder, will this functionality be ever included in this module? The first post in this thread was posted in 2011 and there is already a solution.

I have done the same:
- update Commerce Paypal via the Reports-Available Updates->Update link
- flushed cache
- copied the patched file to [site home]/sites/all/default/modules/commerce_paypal/modules/wps/commerce_paypal_wps.module
- flushed cache

Appears as if it is working fine.
The "send itemized details" was still checked in the workflow rules.

I wholeheartedly agree ... this feature should be rolled into the base code so we don't have to keep patching after each update.

- Jeff

Patch in #73 appears to be good.

Created a patch based on #73

I found that if the tax rate is passed to PayPal with more than two decimal places, PayPal will ignore the value passed in.

Minor adjustment to the patch attached.

(P.S. This patched saved my bum today, so a million thanks! It seemed to otherwise work perfectly.)

patch applied and worked as expected. no issues so far with or commerce_tax as far as i can see, havent tried with commerce_vat yet.

The shipment amount is not included when arriving on paypal, even after applying #78

Why this patch hasn't been included after 2 releases?
I wouldn't like to use a patched module on a live site since I am not an expert developer..

Likely because we need more eyeballs on it to review it and mark it RTBC.

jmary - I am passing shipping to Paypal no problem. It is flat fee -- not sure if that makes a difference... but it IS possible, it seems.

Previous patches do not account for discounts. When adding in commerce_discount / commerce_coupon, it tries to pass the discount as a product line item.

So, I've changed it to allow for discounts in the same way as it does shipping -- sum all the discounts into one line item, and pass it in Paypal's "discount_amount_cart" field.

patch in #78 has worked for me on multiple sites that are in production ... will try #84 later

Looks like 84 didn't upload.

Oops!

There is an error on line 451 once the code is applied, a typo indeed.

Replace currentcy par currency.

Then that patch has solved my problem whereas #78 was not.

patch with typo addresses

Hi,

I applied the patch and works perfectly for the cart items insertion on PayPal WPS side. Thanks a lot for the contribution.

However I'm bit puzzled by the address part, it seems like it's ignored and I get no Seller Protection, neither the address is visible when I want to print the label from PayPal. And to add to the confusion I don't understand the mixup billing and shipping in different discussion threads.

Reading other address related issues like the following https://www.drupal.org/node/1872804, the suggested patch #12 contains the following:

  $data['address_override'] = 'true';
  $data['showbillingAddress'] = 'false';

  ... address filling part ...

  $data['no_shipping'] = 0;

I understand from https://www.drupal.org/node/1494586 in patch #4 that the $data['no_shipping'] = 0; means the following:

  $form['no_shipping'] = array(
    '#type' => 'radios',
    '#title' => t('PayPal shipping address prompt'),
    '#options' => array(
      0 => t('Prompt for an address, but do not require one'),
      1 => t('Do not prompt for an address'),
      2 => t('Prompt for an address, and require one'),
    ),
    '#default_value' => $settings['no_shipping'],
  );

Is the configuration I above-mentioned required to get the shipping address to be considered on PayPal WPS side?

Thanks,

Francesco

I'm getting the product name transferred to PayPal, but I'm using "Commerce Custom Line Items" module. I have the views show those line items as part of the products, but I'm not sure if the views are what is sending the product information to PayPal. Do I need to modify the module to allow for the Custom Line Items or is this something you can implement or can I do it with a view and which one do I need to edit?

Thanks,
Mark

The patch in #89 works well.

However if you enable the sending of itemised order data to Paypal and your site calculates VAT per order, Paypal will calculate VAT per item so for multiple items it will cause a discrepancy.

The order total you will get on a multiple item order will be lower than that which Paypal calculates unless the calculation is exactly divisible (in which case it will be the same)

So for example you have

33 x items at £5.34 = £176.22
VAT at 20% calculated on total is £35.24
Total shown in DC as order total is therefore £211. 46

Paypal will calculate it thus
£5.34 * 1.2 = £6.41 Paypal clearly rounds up
£6.41 * 33 = £211.53

Paypal calculates a price 7p dearer than Drupal Commerce.

This is an issue if you show ex vat prices in the line items, if your price is incl VAT it may not be an issue.

I don't know a lot about VAT - I think it's similar to sales tax here in the US. If it's a tax that's applied, then I think part of the issue is that we shouldn't be calculating it on the store site, then having PayPal calculate it again. My expectation would be to NOT have the site calculate the tax at all, and say "VAT costs will be shown during checkout," or even better, we calculate the VAT on-site, and pass that over to PayPal as a line item, so that it does not get calculated on the PayPal side at all.

My hunch is we're calculating it on-site, not passing it over, and then re-calculating it @ PayPal.

What I don't know is whether we can we pass VAT to PayPal as a line item (like we do with, say, shipping costs). We already do pass the tax for the cart over - so I'm not sure if VAT is a separate field, or what...

My understanding is that you can optionally configure profile-based calculation of tax at the PayPal website. (See https://developer.paypal.com/docs/classic/paypal-payments-standard/integ....) I can think of two ways it may be possible to address this.

1. Turn off profile-based tax calculation. This is up to the user, not the module.
2. Override tax calculation by explicitly setting tax to 0.00 (or some other correct amount) for the data we transmit to PayPal.

The first would seem to me the easiest.

Re #90, in the end I added $data['address_override'] = 1; so the address is shown on PayPal side.

$data['showbillingAddress'] = 0 doesn't seem having any effect, but it's not an issue for me.

$data['no_shipping'] = ; I applied the changes to make this a settings selectable from the edit form.

Last but not least I pass the Shipping address and not Billing because on PayPal side it's "Delivery Address".

And I get Delivery Address shown on PayPal side with Seller Protection enabled, of course destination label printing is fine too.

I think the issue in comments #90 and #95 are due to the fact that the code populating the form submitted to PayPal is using !empty() rather than isset(). So the values 0 and '0' will both be ignored.

The attached patch converts the !empty() call to isset().

Nice catch!

Wait, though, it appears we never actually committed the itemization patch. So is your patch to the patches above or for the module as is?

Yeah it looks like #96 is just a patch to the already patched version, or more like an interdiff. I can re-roll #89 with the tweak in #96?

96 doesn't' make sense in this context, now that I'm trying to merge and reconcile. That is, that line in my patched version doesn't have an if() wrapper around it at all. So, not sure where this is coming from... does this belong in a separate issue?

Looks like it probably does. I'll review this patch and try to get it in this afternoon and can spawn the follow-up for #96 if need be.

Ok, I'm actually going to commit the !empty() -> isset() change, because that one's easy enough. However, for this issue, I'm not sure I want to introduce a specific accommodation for commerce_option. I've never supported that module and don't want to have to maintain code against it indefinitely.

Reviewing the patch as written, I'm also not sure we should be changing the cmd attribute from _cart to _xclick. Are we sure this shouldn't stay _cart w/ upload = 1? It's always worked fine as is, and technically we're already sending an itemized cart - we just reduce it to a single item instead of reflecting line items on the order.

Finally, I don't want to commit to this until we're sure it doesn't create tax related issues. I think it's fine to document that PayPal calculated VAT should be disabled, but is there any other gotcha here?

Hi

I could find no way in paypal to disable it from calculating VAT, So if you commit this patch then the UI needs to warn that Paypal, upon receiving itemised orders including VAT, calculate VAT per item and rounds up rather than per order with no rounding up. This can cause a potential issue where the VAT calculated may be different from the VAT calculated in the order.

The text description of the option should probably read something like:

Please note that sending itemised order details to Paypal including VAT, may cause inconsistencies between VAT values calculated in Drupal Commerce and in Paypal due to Paypal rounding up. You may wish to adjust your VAT calculation rules to match the way it is done by Paypal to avoid confusion.

Tim

@TechnoTim2010 Even based on the notes in #94 above?

Hi Ryan

That does not help too much I chased it through and you would need to change the data sent to paypal to make the calculation per order rather than per item.

So from links at

Overriding Sales Tax Calculations on Individual Transactions

Paypal instructions for changing the tax calculations

This clearly involves changing the value of variable tax_cart in code or by some other method.

Of course
a) this is beyond many site builders and
b) I have no idea how to change the data supplied to Paypal.

Perhaps the code could provide this option.

Meanwhile with no such option or recipe to achieve this the warning should be there.

Regards

Tim

Why can this not be added to the module as another option / tick box.

All this patching seems terribly complicated and scary.

kentjames1980 - yes in general it can be if you're not a developer. I think the current state of the issue is that it generally works, but there is a VAT issue because there's no way to prevent PayPal from calculating its own VAT using a slightly different method.

The next step would be to incorporate the above warning message into the module, perhaps? Maybe @rszrama could provide some insights on direction to take that would result in this being accepted?

Hi Chris

I actually managed to patch it using your patch above using Netbeans which was something completely new to me but my partner required her website working this week and that was the final issue with paypal! Thanks for the patch in #89.

I did have to add in another bit of code pinched from another thread for an earlier release to overcome the address issue / seller protection issue as mentioned in #90

// Send shipping address to PayPal for Seller protection.
    $wrapper = entity_metadata_wrapper('commerce_order', $order);
    $shipping_address = $wrapper->commerce_customer_shipping->commerce_customer_address->value();
    $data['address_override'] = 'true';
    $data['showShippingAddress'] = 'true';

If this is 100% correct or not I do not know but it certainly got fixed our issue!

Thanks again,
James

Can some one please re-roll this patch? I need seller protection and to have the items or the order sent to paypal.

Im very confused to witch patch to apply?

#89 fails
patching file commerce_paypal_wps.module
Hunk #3 succeeded at 429 (offset 5 lines).
Hunk #4 succeeded at 584 (offset 5 lines).
Hunk #5 FAILED at 588.
1 out of 5 hunks FAILED -- saving rejects to file commerce_paypal_wps.module.rej

patching file commerce_paypal_wps.module
Hunk #3 succeeded at 429 (offset 5 lines).
Hunk #4 succeeded at 574 (offset 5 lines).
Hunk #5 FAILED at 578.

does any patch work??

@AntiNSA #89 is applying cleanly for me again 7.x-2.3, but not against the -dev. I've re-rolled it for the -dev. It's just a straight re-roll, so use #89 if you're patching the stable, this one if you're patching the dev.

Chris CWELLS

This was patched and working but the other day we received an order and the address wasnt passed through to paypal which was a surprise?

Does anyone know if paypal has changed or something as we had the patch working fine and now it is not and I am at a loss as to what happened? No modules have been updated recently on our side?

Thanks, a confused James

Can anyone help with the above problem please? still confused why the patch applied no longer works? thanks!

Hi KentJames1980 - sorry to hear this for you; however, I can confirm it's still working fine for me. The itemized cart is still going over to PayPal, even though PayPal's UI has changed.

The address was also pre-filled from what I filled in back on the Drupal Commerce site.

Patch doesn't work for unsupported paypal currencies, because the conversion of line items is wrong. I am applying a patch which is fixing this one.

Patch not working when using the PayPal button from the Cart page (before collecting shipping address for tax and shipping). Tax or shipping line items are not sent to PayPal.

When using PayPal after the shipping page, the patch is not needed. Both tax and shipping line items are sent to PayPal.

I've tried both patches - 116, 112. The item list isn't passed to paypal, the a dress however is. Maybe there has been an update in the data format by paypal?

For anyone using the patch at #116 , the shipping amount sent to paypal is being converted to decimal twice for summarized carts, so a shipping cost of 10.00 will end up being sent to paypal as 0.10.

The fix is to remove the duplicate commerce_currency_amount_to_decimal() call from the line item loop, so:

$line_item_amount = commerce_currency_amount_to_decimal(commerce_currency_convert($line_item_price['amount'], $line_item_price['currency_code'], $currency_code), $currency_code);

becomes

$line_item_amount = commerce_currency_convert($line_item_price['amount'], $line_item_price['currency_code'], $currency_code);

Does anyone know if any of these patches work with the latest (2.7) release? I’ve tried applying a few different ones and always get errors, though it’s possible I’m doing something wrong.

Okay, I got desperate and did a couple tweaks to get cwells's patch at #112 to work with the May 6, 2019 2.7 release, so here's the patch for that if anyone else needs it.

Only glitchy bit remaining is that PayPal labels flat-rate shipping charges as "handling" but that's not a big deal.

Just tried patch #121. The line items are going across now. Saved me hours no doubt. However the postal address isn't? If I try to pay without a PayPal account the address is filled in.

How can we have it on the payment? Isn't that needed for seller protection so that we can prove delivery?

After applying patch #121, I don't understand what the code under

// Pass billing information to Paypal if we collected it.

& code under

// If a billing address is available, pass it to PayPal to populate
// field values for non-PayPal users paying with their card.

is doing different? Seems like a duplication. As they are setting the same variables aren't they? Am I mis-reading it?

For myself I wanted to send the shipping info, not billing. As I understand the address gets stored to the transaction in PayPal. It is that address that we must send the items to and provide tracking numbers as proof of delivery. Otherwise we aren't covered by seller protection. If anyone knows any different can you speak up so I get it right too. Pretty sure that is the case. It does kind of leave the billing details redundant. I can't see how to send them both.

Also I found that no address was getting set even with patch from #121. That patch wouldn't apply cleanly either. So I manually applied the changes in my install.

My attached patch is pretty much patch #121. Other than the shipping address gets sent. It is shown to users at PayPal. They can't change it at PayPal. They are forced to return to our site to change it. This gives us consistency with the address on the transaction and the shipping field in Commerce. We can just use Commerce to manage orders.

When being redirected to PayPal, I was getting errors on the screen on the redirect page. Although the payment proceeded as normal, who likes errors, especially at the point of payment. It might scare people off completing. It was when non-required address fields was empty. So I added checks for that.

For my own reference as much as anything, here is the PayPal docs for WPS: https://developer.paypal.com/docs/classic/paypal-payments-standard/integ...

I thought it was the case with shipping. This is from PayPal's T&C's 11.6:

c .For tangible items, post the item to the shipping address on the “Transaction Details” page. If the item is delivered in person or if the Payment Recipient posts the item to a different address (for example, if the buyer asks that you send to another address on the basis that it is a “work address” or a “gift” address) then you will not be eligible for re-imbursement under the terms of the ("Seller Protection") programme.

https://www.paypal.com/webapps/mpp/ua/useragreement-full#r011

The billing info still has a purpose to me for VAT invoices.

Thanks, gMaximus. I don't send addresses to PayPal so I didn't even consider that part. We only sell subscriptions and back issues, so seller protection isn't a concern, but I'll keep it in mind if we start selling anything else!

No worries. Hope it helps others.

I found out that WPP doesn't qualify for it either. So for tangible items at least, this is the safest module to use. Although if you let them checkout without a PayPal account you aren't covered for that either.

I'm pretty pleased I read it properly.

Has anyone ported this to WPP?