rtddev

@dynamiczach @jamosova – Seems as though we have the exact same issue as described here in this thread.

Similar in regard to the need to include some sign-up fee in order for the WooCommerce PayPal Checkout Payment Gateway payment option to show at checkout for a subscription payment.

I have a non-prorated variable subscription product, renews on the 1st day of the month, allowing the subscription to be setup without any cost.

With that configuration, this plugin’s payment method does not get displayed — it gets suppressed.

In the very same variable subscription product, if I add a Sign-up fee of $0.01, the payment method from this plugin is shown.

Appears to be related to some recent update of the WooCommerce PayPal Checkout Payment Gateway plugin.

Per your above recommendation, I will open a new ticket with the WC Subscription plugin via our WooCommerce.com account, and reference this support thread.

In addition, I will try and download prior versions of this plugin to see if I can trace back where the issue was introduced.

• This reply was modified 5 years, 9 months ago by rtddev. Reason: To check "Notify me"

Thanks Pavel.

Just submitted a ticket per your request.

Hi Pavel,

Sorry for my delayed response — I didn’t see your reply until now.

Inspect (Console) is showing no errors when I load the ATUM > Stock Central page, nor is it triggering any errors when I attempt to click the “14”.

Also, I checked the PHP error log, and the only two errors being thrown are (examples):

[04-Feb-2019 19:13:02 UTC] The WC_Customer::get_country function is deprecated since version 3.0. Replace with WC_Customer::get_billing_country.
[04-Feb-2019 19:13:21 UTC] The WC_Customer::get_country function is deprecated since version 3.0. Replace with WC_Customer::get_billing_country.
[04-Feb-2019 19:57:26 UTC] PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set ‘always_populate_raw_post_data’ to ‘-1’ in php.ini and use the php://input stream instead. in Unknown on line 0
[04-Feb-2019 20:02:30 UTC] PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set ‘always_populate_raw_post_data’ to ‘-1’ in php.ini and use the php://input stream instead. in Unknown on line 0
[04-Feb-2019 20:07:04 UTC] PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set ‘always_populate_raw_post_data’ to ‘-1’ in php.ini and use the php://input stream instead. in Unknown on line 0

Any thoughts?

@angelleyesupport – one other thing I just learned.

PayPal is not enabling any new accounts with the ability to process credit card payments via the REST API.

Some older accounts are grandfathered into having the ability to use the REST API, but any newer accounts won’t be able to use the REST API.

They’ll have to use Websites Payment Pro, Payments Pro 2.0 (PayFlow), or Braintree.

If you use Braintree, then you don’t have the convenience of going to one single account to see both Credit Card & PayPal transactions.

I do recall reading something about the above limitation somewhere before, but PayPal Manager support just confirmed to me that the REST API is in a temporary holding pattern.

As such, instead of REST, we’re now using PayFlow within the plugin, and everything is working good so far.

@angelleyesupport – done! Thanks.

@angelleyesupport – Looks like we never signed up for PayPal Pro on this particular PayPal account.

Just signed-up, so I think we’ll be good to go once our application has been processed/approved.

I’m going to go ahead and mark this as resolved since it’s not related to the plugin.

Thanks for your timely response!

@angelleyesupport – Thanks Oliver.

I’ll give them a call, see what they say, and report back here in a bit.

@rtaveira Sent ??

@rtaveira If you’d like to buy a copy of the plugin we made, let me know.

It would be unsupported, but I can connect you with the our developer who can help you further develop it.

We migrated off of PaySimple, so we stopped development — though we were making some pretty good progress.

Let me know.

Hi Oliver,

Thank you for the clarification.

We have been able to run a successful transaction via Payflow now, so it is possible & likely that we did not save the password information correctly.

It is strange that the API sent back an “invalid vendor” error response, but that would not be the first time I’ve seen odd things like that.

Next up is to confirm that tokenization is working, since that is our primary objective (to store payment information by way of the token).

As for that other post I was referring to, I was sent an email notification with that information that appeared to come from this thread.

Maybe the original author deleted it after they posted it. I’m not sure.

At this point, this particular issue is resolved, so I will mark this thread as such.

If we run into any issues with tokenization, I will open up a separate support thread related to that specifically.

@angelleyesupport – I just saw another user post something similar related to this issue, but it is not showing up on this thread.

Here is what I received.

dalamar17 wrote:
I am having this same issue and cannot get it to work even with PayPal’s technical engineer. Very frustrated! Have tried creating new payflow accounts, verified all credentials and account status, etc.

@angelleyesupport

Ok, will look into it, but what about the issue I reported wrt the User (Optional) field always getting populated?

That doesn’t seem right. It’s an optional field, and if we don’t enter anything in that field, it should be left blank, right?

@walshie1987 If I’m not mistaken, that is a native WooCommerce setting.

It’s not likely related to this or any particular plugin.

Goto WooCommerce > Settings > Products > Inventory and remove any value that is present in the Hold Stock (minutes) field.

Normally that is set to 60 minutes (to reserve inventory). If an order is not paid, then WC will cancel the order and release the inventory for use.

If you remove the value from that field, it will disable the option and not auto-cancel unpaid orders.

With the above said, when you stated you “have just taken an order”, which kinda implies it was paid.

If it was paid, and there is a record of it, then the setting above is not the cause.

But, if you received an error stating “Unpaid Order Cancelled”, then I’m pretty sure that order was never actually paid and moved to Processing. So, the above setting change should fix the problem.

Thanks Oliver!

Thanks Oliver @angelleyesupport

Do you have any idea when it will be updated and released so I can put a reminder on my calendar?

Also, I’m not sure if this is related, or something different, but when I was testing using our Sandbox Credentials, we were getting Response Status 500.

I did 4-5 tests, and each time got the 500 error.

Then, I switched over to the Production Credentials and it worked as expected.

I know the requests were getting to PayPal Sandbox, because we saw the requests in the Sandbox dashboard, but it wasn’t clear why we were getting the 500 response.

This was the error:

[28-02-2018 02:47:08] PayPal\Core\PayPalHttpConnection: ERROR	: Got Http response code 500 when accessing https://api.sandbox.paypal.com/v1/payments/payment. {"name":"INTERNAL_SERVICE_ERROR","message":"An internal service error occurred.","information_link":"https://developer.paypal.com/docs/api/payments/#errors","debug_id":"913cc9dd6919d"}
[28-02-2018 02:47:08] PayPal\Core\PayPalHttpConnection: DEBUG	: 

Any thoughts?