Open AmeliaBriscoe opened 7 months ago
I am not sure who is the right team to work on this issue, so I will tag both @diegocurbelo from Quark and @FangedParakeet from Heisenberg. Could you please decide which team will work on this issue? As a Gamma porter, I will move this issue to Other Teams queue as a part of our triage process.
@zmaglica, I think it makes sense for Heisenberg to take on this task. I've added it to our triage queue for maintenance issues.
Definitely inconsistent behavior. Thanks @AmeliaBriscoe for raising this issue. @nikkivias fyi another example related to PRB buttons visibility inconsistency.
Another report in 7883759-zd-a8c
Just noting here that with the move to Express Checkout Element, we'll want to tackle this issue in that implementation if it is still present.
Hey team! Please add your planning poker estimate with Zenhub @asumaran @cesarcosta99 @lovo-h @rafaelzaleski @reykjalin @ricardo
I don't recall the exact limitation for trial subscriptions that require shipping, but the button is hidden on purpose: https://github.com/Automattic/woocommerce-payments/blob/78fba818fc3462ce4f475041a03cff0256ce2cad/includes/class-wc-payments-payment-request-button-handler.php#L882-L885
The change has been there since the PRB implementation https://github.com/Automattic/woocommerce-payments/pull/1175
also reported in 8484825-zen
We bumped the estimation from 2 to 3 because the scope/effort for this task was bigger than we anticipated.
The PRB buttons work on the product page because they pass the value of the product to the gateway when the user clicks on them. That value is displayed in the modal, but when the user pays, they're not charged, apparently. I confirmed the WC order total value is 0.
In the cart and checkout pages, the gateway receives a value of 0 because that's the cart total. Since the gateway doesn't allow 0
, the current implementation is deliberately hiding the buttons.
I've opened #9309 to address this issue but the code still needs some hardening and there are a couple of gaps to be filled. The idea of that PR is to identify if there is trial subscription in the cart and inform the actual value of the subscription to the gateway, similar to what happens in the product page. That way the user will be able to use the PRBs to pay, but won't be charged initially.
One thing to be confirmed yet is whether this approach doesn't really generate a charge. If the user is not initially charged, we can proceed with the PR, otherwise, we may need to hide the PRB from the product page and declare PRBs incompatible with trial subscriptions.
I'll be pausing the work here due to priority changes, but plan to come back to this very soon.
Describe the bug
Customers are having trouble getting Apple and Google Pay buttons to show on the cart/checkout page for any subscription that has a free trial.
However, buttons show up on the product page when the subscription is a digital product. The buttons do not show when it's a physical product.
To Reproduce
Actual behavior
It's not clear on what the expected behaviour is supposed to be when it comes to products with a free trial. The behaviour seems to be inconsistent and is not clear to the customer in the documentation.
Additional context