Forum Replies Created

Viewing 15 replies - 1 through 15 (of 16 total)
  • borish1


    Some additional notes:

    On the image, you can preview part of the invoice from the PayPal dashboard.
    The part that is important is the CUSTOM row which is basically a “Note” by the PayPal API documentation.

    That functions of yours custom() is passing only order_key but I need order_id as well.

    I hope this helps :).



    Hey Andreas,

    Yep, I modified it but directly inside the files (only on my development server to test it). The file is located inside /src/payment/ folder by the name of patchProvider.php.

    The key part of the functions is this one

    Currently, your plugin, upon successful creation of the invoice is sending custom data which in this case is wc_order_key.

    Now if we go back to 1.1.1 version of this plugin it actually sent both the wc_order_key and and order_id which is this part of code that I changed into:

                    'order_id' => $this->order->get_id(),
                    'order_key' => $this->order->get_order_key(),

    Now my client is using third party software which pulls data via PayPal API from his PayPal account to double-check the order_key and order_id from the invoices but in 2.0.4 version we only have now order_key.

    That is the main reason why I needed that order_id.

    It would be good if you can put filter there so we can then add additional data without need to edit the core files of the plugin.

    Hey @perryrylance,

    I tried switching version from 7.0 to 7.3 with no changes (don’t want to go with lower version of PHP because of one plugin, no point).

    libxml is installed, I confirmed that via phpinfo(); but still no fix.
    – I tried speaking to the support of the shared hosting but they told me that -enable-dom flag is not added at all.

    I went back to the older version since this is the last resort I can rely to currently. I hope you fix this in the next version. The version in which the error doesn’t occur is 7.10.18.

    I tried 7.10.19 and it gives back same error so in that version there were some changes regarding this issue. Hope it helps you.



    Hey @aweissinpsyde,

    Sorry for a little delay. I sent you the last message from here to as requested. If you need any further information do not hesitate to reply.

    Kind regards,



    @aweissinpsyde, maybe we could, after all, fix this (regarding an issue with the order_key):

    To answer your question Datev gets the data directly from PayPal. The user logs in to the Datev system and has access of the payments etc that are pulled directly from PayPal. There are no custom inputs available for me to change in the Datev System. (as far as my clients tell me).

    So once the Datev system pulls the data from the PayPal it looks something like this (part of the system)

    As you can see under “Text” it gives back those 2 parameters order_id and order_key.

    This is the 1.1.1 version passing both order_id and order_key:

    This is the 2.0.2 version passing only order_key

    Can we somehow bring back passing of both again?

    • This reply was modified 7 months ago by borish1.


    Hey @aweissinpsyde,

    I’ve reverted the plugin to the older version 1.1.1 since we have little information as to how is Datev Zahlungsverkehr system setup because other company did that. I don’t have thorough input for you so we could inspect further what is missing where. I will need to find a way for this to work again.

    Additionally, I wanted to ask you about the 404 error that triggered. While two payments went through with no problem one went with 404.

    [09-05-2019 06:06:51] Inpsyde\Lib\PayPal\Core\PayPalHttpConnection : ERROR: Got Http response code 404 when accessing***********************. {"name":"INVALID_RESOURCE_ID","message":"The requested resource ID was not found","information_link":"","debug_id":"956070d36d1df"}

    Any way I can debug this as could what could have caused it?



    Having the same issue. Any help appreciated.



    Had the same problem but I found a solution to it. Basically what UM does is if class_exists(“WooCoommerce”) it dequeues select2 both style and script. There is a hook called “um_dequeue_select2_scripts” to remove the select2 that UM adds but that works only partially as the case for this to work is actually this one:

    $dequeue_select2_status = apply_filters(“um_dequeue_select2_scripts”, false);
    if(class_exists(“WooCoommerce”) || $dequeue_select2_status)

    This means that you cannot really force it to be removed if you have woocommerce active. What you can do is deregister and dequeue select2 and then re-enqueue one for the woocommerce as a solution for now. That will bring both functionality and style of the default woo. Also make sure that your “wp_enqueue_scripts” is above priority of 100 as theirs is 100.

    Hope it will help someone.

    Hey @kleroy,

    When you go to the UM form builder and create a new field or edit the existing one you have Privacy on the right side (preview here: You just set the option to “Specific role” and then change it to be admin only. That helped me remove the duplicate fields.



    Made the import. Issue with the import of the orders is that they not recognize Taxes (and they are not calculated at all) even though I created standard and reduced taxes exactly as they appear on the old website.

    Additionally, after a few tests I could say that this is happening only for the logged out users. Logged in users don’t have any issues as I see currently



    Hey @decomteam,

    Sorry if I didn’t explained good. What I was saying is if there is any chance to exclude sale prices to be counted. I don’t have VAT / Taxes or any other % value on the cart so I don’t need to worry about those. Only thing turned on is shipping but that comes at the checkout so that can also be ignored. What I did is this:

        	$items_on_sale = 0;
        	foreach ( WC()->cart->get_cart() as $cart_item ) {
        		$_product =  wc_get_product( $cart_item['data']->get_id() );
    		   $items_on_sale += $cart_item['data']->get_price();
            $total = WC()->cart->total - $items_on_sale;

    I think this should work as intended if we consider that I don’t have anything turned on from above mentioned. Correct me if I’m wrong and thank you for the fast response.

    Hey Andreas,

    Thank you for your fast reply.

    Problem is that I have this setup working good in the last 5-6 months. We never had issues with payment at all. I think this started happening after we got woocommerce set on 3.4.0 but I cannot be 100% sure. This is more of a guess that needs checking out.

    Ok I tried disabling woocommerce germanized and it did fix the issue with those 2 fields that I added.But I cant say for sure it cleared all the problems.

    Does this mean that woocommerce germanized and paypal plus cant work together? I mean I used the before with no problems I’m not sure how this all happened.


    After numerous testings, I found out that if I check for shipping options (in which I included 2 additional fields because my client needs them (packstation and packstation number) It fails returning an error “Fehler im Bestellvorgang. Versuche es bitte erneut.”

    Is this because paypal plus plugin is trying to validate those fields? Any way I can bypass and fix this?

    Thank you in advance.

Viewing 15 replies - 1 through 15 (of 16 total)