thenbrent

Hi @mlynch1107

As you know, we have now resolved this issue via our support system and the balance of your account is now in your bank account. Thank you for your patience while we resolved this issue.

As also mentioned via our support system, I’m terribly sorry for the bad experience you had here. The trouble this situation caused you and your customers is not something we want any merchant to experience with WooCommerce.

Now that the remainder of your account balance is in your account, I hope your business will continue to be successful and I’m glad to see you’ve been able to continue to operate with alternative payment methods on WooCommerce.

• This reply was modified 4 years, 1 month ago by thenbrent.

Hi @piercerides,

With version 1.2.0 of WooCommerce Payments, we’ve:

• Started displaying the 7 day cancellation period next to the Manual capture setting instead of being only displayed in a tooltip.
• Added a confirmation dialog when enabling Manual capture, which explains authorizations are cancelled after 7 days.
• Set orders to transition to the cancelled status when the authorization is cancelled to better communicate the authorization lapsing and to make sure the capture action is not available on an order which can not be captured.

Thanks again for your feedback to help us improve WooCommerce Payments.

Hi @mochel232 it should also be possible to use the free Say What plugin to customize the Credit Card text.

Hi @piercerides, I’m sorry that this has been your experience with WooCommerce Payments. We are working to create the best possible merchant experience with this software, and have fallen short here for you.

I’ve opened an issue for us to improve how authorization expiration is:

• communicated when the Manual capture setting is enabled, and
• handled on orders that were not captured within 7 days.

We will work to get improvements for that shipped in the next minor release.

We currently attempt to communicate the 7 day expiration via the tooltip on the Manual capture setting and in the documentation for Manually capturing charges.

Your experience has made it clear this is not going far enough for such an important piece of information. Thank you for sharing your experience with us to help us see that and improve the software. It will help prevent other merchants encountering this issue in future.

• This reply was modified 4 years, 5 months ago by thenbrent.

Hi @richiemccoy, sorry to hear you’re having trouble! That is certainly not expected behavior. I checked your account and see the payments in there, so they should be showing up in your WordPress dashboard.

We will need to investigate the issue more closely on your WordPress site. Please open a ticket on WooCommerce.com and include all information requested on that form so that we can investigate further.

Hi @allofmalls I’m sorry but once an account has been reviewed by Stripe and a decision made by them, that decision remains in place unless they decide to reverse it.

WooCommerce Payments is a service separate to the WooCommerce software. Your store’s catalog will remain online and able to accept orders via other payment methods.

We support many businesses accepting payments via Square, PayPal and other payment providers. You can download a free Square and PayPal integrations via WooCommerce.com or www.ads-software.com then continue to sell via your site with those payment gateways.

HI @buzzmandt, thanks for reaching out.

WooCommerce Payments uses a special Stripe Express account that is created when you sign up for the service. Because of that, it is not possible to use an existing Stripe account with WooCommerce Payments.

If you complete the sign-up process to be issued an Stripe Express account, your existing Stripe account will remain in place and you can continue to access that account and its data via Stripe.com with its existing login information.

Alternatively, can use the free Stripe extension to use that Stripe account on your WooCommerce store.

Hi @romchyk16, thanks for reporting this issue and providing the screenshots. I’ve opened an issue with the development team to investigate.

Hi there,

I’ve checked the status of those 3 payments. All 3 remain incomplete as they are pending 3D Secure verification, that’s why they are not showing up in your transactions list.

I see the related orders are set to Processing in your store. I do not believe that is the correct status and I will open an issue internally for us to review.

Thank you for providing the transaction IDs, screenshot and videos, as these made it easier to investigate. However, please remove these from your replies now, as they include private information about your customers that should not be shared on a public forum.

In future, please submit questions like this via our support form so that the information remains private.

Thanks for the quick turnaround @nmedia!

Thanks @nmedia. That’s super helpful and exactly what I needed!

I’ve traced the issue back to the ppom_get_product_id() function.

When passed a variation, ppom_get_product_id() is returning the parent variable product’s ID. When passed a subscription variation, its returning the variation’s ID instead of the parent variable subscription product’s ID.

This is because ppom_get_product_id() checks if a product is a variation with this code: $product->get_type() == 'variation'.

It’s better for compatibility with 3rd party plugins, like WooCommerce Subscriptions, to check using the WC_Product::is_type() method, like this: $product->is_type( 'variation' ).

That way, child variation product types, like a subscription variation, will then also be seen as a variation and you can apply the same behaviour to them.

If the check in ppom_get_product_id() is changed to $product->is_type('variation' ), then I can confirm that the PPOM meta data is being displayed correctly for Variable Subscription products.

Do you think you’ll be able to add this patch to PPOM?

Hi @nmedia, can you please let me know which WooCommerce hooks you are using on cart/checkout pages to display meta?

If you can also provide a link to to where your source code is adding meta data to the cart item, that would be a great help for us to diagnose the conflict.

• This reply was modified 5 years, 5 months ago by thenbrent. Reason: Requesting link to source code for adding meta. Removing other comments

I cleared my Siteground cache from cPanel and believe that may have solved the issue for me.

@mj4455 that’s a great tip, thanks for sharing!

We noticed that around 70% of our customers had been changed to ‘manual renewal’

@autonomite that is a different issue. It occurs when WooCommerce was upgraded prior to upgrading Subscriptions to 2.2.0 or newer. If you have not already, please immediately submit a support ticket to WooCommerce.com Support and we will be able to fix up the subscriptions.

I need to make this simple change in line 305:

You can use a very similar approach to the one I mentioned previously – find hooks before/after when that code is called, then use them to attach a callback to the 'woocommerce_can_subscription_be_updated_to_' . $status hook.

For this case, the hook you’ll want is 'woocommerce_can_subscription_be_updated_to_cancelled'. You’ll have to find the appropriate hooks to attach your callback on your own though. ??

@imoyano you can achieve what you want indirectly. From your snippets, it looks like all you want to do is make sure that the active status isn’t displayed as an option on the WooCommerce > Edit Subscription screen. This is effectively the same as saying a subscription can’t be updated to wc-active status from that screen.

You can use the 'woocommerce_can_subscription_be_updated_to_active' filter to enforce that.

You should also add some additional code to make sure you are only acting on that filter when in the WCS_Meta_Box_Subscription_Data::output() function (i.e. on the WooCommerce > Edit Subscription screen).

To do that, you can use something like the code below:

function eg_add_status_filter( $post_type, $context, $post_object ) {
	if ( 'shop_subscription' === $post_type && 'normal' == $context ) {
		add_filter( 'woocommerce_can_subscription_be_updated_to_active', '__return_false', 100 );
	}
}
add_action( 'do_meta_boxes', 'eg_add_status_filter', 0, 3 ); // 

function eg_remove_status_filter() {
	if ( 'shop_subscription' === $post_type && 'normal' == $context ) {
		remove_filter( 'woocommerce_can_subscription_be_updated_to_active', '__return_false', 100 );
	}
}
add_action( 'woocommerce_admin_order_data_after_order_details', 'eg_remove_status_filter' );

Note: that code is not tested or meant to be a final working snippet, it’s intended to illustrate the workaround and provide you with a good head start on the code needed.

The eg_add_status_filter() function in that snippet attaches WP’s __return_false() function to make sure no subscriptions can be updated to the “active” status. It is attached to the ‘do_meta_boxes’ hook, which is triggered just before WCS_Meta_Box_Subscription_Data::output() is called to print the status select box on the the Edit subscription screen.

The __return_false() callback is then removed in eg_remove_status_filter with eg_add_status_filter() just after printing the status select field on the the Edit subscription screen but removing that callback on the 'woocommerce_admin_order_data_after_order_details' hook.