Cancel Purchase: show marketplace subscriptions dialog.

[cpapazoglou]

Proposed Changes

Testing Instructions

Pre-merge Checklist

Complete applicable items on this checklist before merging into trunk. Inapplicable items can be left unchecked.

Both the PR author and reviewer are responsible for ensuring the checklist is completed.

• [ ] Have you written new tests for your changes?
• [ ] Have you tested the feature in Simple, Atomic, and self-hosted Jetpack sites?
• [ ] Have you checked for TypeScript, React or other console errors?
• [ ] Are we memoizing when appropriate (for expensive computations)? More info in Our Approach to Data and Memoizing with create-selector and Using memoizing selectors
• [ ] Have we sent any new strings for translation ASAP?

Fixes #65235

[github-actions[bot]]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-44895

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-44895&env=jetpack

[cpapazoglou]

This is still WIP, I am having a problem getting the ProductList.

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~1063 bytes added 📈 [gzipped])

name                    parsed_size           gzip_size
site-purchases              +3875 B  (+0.3%)     +904 B  (+0.2%)
purchases                   +3875 B  (+0.2%)     +904 B  (+0.2%)
domains                      +668 B  (+0.0%)     +161 B  (+0.0%)
settings                     +149 B  (+0.0%)      +45 B  (+0.0%)
jetpack-cloud-settings       +149 B  (+0.0%)      +57 B  (+0.0%)
email                        +149 B  (+0.0%)      +57 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~380 bytes removed 📉 [gzipped])

name                                                    parsed_size            gzip_size
async-load-calypso-blocks-product-plan-overlap-notices      -1219 B  (-23.1%)     -380 B  (-20.0%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory. Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[epeicher]

Applying this branch displays the Modal as expected but the subscriptions are not removed.

I am going to investigate

[cpapazoglou]

The intention is that marketplace subscriptions are note removed when canceling a purchase. They should remain functional until subscription expires and plan gets removed. I haven't updated the copy at all though here.

[epeicher]

When following the Cancellation flow instead of the Removal flow (reference here), the following modal will be displayed:

[epeicher]

Question asked in the linked task to confirm the approach before proceeding

[epeicher]

I have uploaded some changes to handle Marketplace subscription removal and cancels. I have refactored a bit the cancel-purchase/button.jsx component to use async-await as it simplifies the code when using a collection of asynchronous tasks.

The following video has been recorded with a test done cancelling a plan that is more than 14 days old and it was paid using credit card

https://user-images.githubusercontent.com/3519124/192029990-73edc6a3-6262-4dc0-8e10-e7813858ef65.mp4

[epeicher]

The following video has been recorded showing the flow when the system allows Cancel and Refund:

https://user-images.githubusercontent.com/3519124/192214808-2cd26e3f-bef8-40d0-973e-15898b14e573.mp4

In this scenario both the Plan and the Plugins are refunded

[cpapazoglou]

The modal though still has the wrong content, it should look like this

When the user is allowed to Cancel and Refund (example video here): The site plan is immediately cancelled and refunded The plugin is immediately cancelled and refunded

The plugin should not get refunded if the refund period has passed. Example:

• I renew an annual plan now
• My plugin annual subscription expires in 5 days

If I Cancel my plan:

• plan should get refunded and removed
• plugin should be removed - no refund for the plugin

[epeicher]

Heads up, after the following changes https://github.com/Automattic/wp-calypso/pull/68088/files the logic of Cancel and Cancel and Refund is the same but the wording has changed.

[epeicher]

@cpapazoglou thanks for the wording suggestions. I have changed them but maybe we should update it again to cover additional scenarios.

Regarding the logic implemented, I think it is correct but the description was not accurate. Let me summarise it:

Removal flow:

This has not changed as part of this PR. When the user removes a plan, everything seems to be removed. This could be handled in a follow-up task if it is not correct.

Cancellation flow

• User cancels a plan. Regardless of the plan being refundable or not:
• For each subscription:
  • If the purchase is cancellabe, it will be cancelled. This means auto-renew of the plugin will change to OFF
  • If the purchase is cancellable and refundable, it will be cancelled and refunded. This means the plugin is removed immediately.

Please see this video with a scenario with:

• A site plan that can be cancelled and refunded
• A plugin that can be cancelled and refunded
• A plugin that cannot be refunded

With the above logic, that means that some subscriptions could be refunded and removed immediately and some others will be just cancelled. Should we adapt the wording of the Dialog to the following more generic?

The subscriptions will be cancelled.

[cpapazoglou]

User cancels a plan. Regardless of the plan being refundable or not: For each subscription: If the purchase is cancellabe, it will be cancelled. This means auto-renew of the plugin will change to OFF If the purchase is cancellable and refundable, it will be cancelled and refunded. This means the plugin is removed immediately.

The plugin subscriptions should depend to the plan being refundable or not, since when the plan is refundable and gets refunded it will get removed, site will get downgraded, plugins will be unusable. In this case (copying exactly what you have suggested which is correct) :

For each subscription:

• If the purchase is cancellabe, it will be cancelled. This means auto-renew of the plugin will change to OFF
• If the purchase is cancellable and refundable, it will be cancelled and refunded. This means the plugin is removed immediately.

But if the plan is not refundable, it won't get removed - it might even expire after 364 days. In this case, plugins should not get refunded - removed. For each subscription we should disable auto-renew and make sure the user is aware.

Should we adapt the wording of the Dialog to the following more generic?

Yes, feel free to adapt as needed.

[epeicher]

The plugin subscriptions should depend to the plan being refundable or not,

Ok, that makes sense. Thanks for your input! I am going to update the logic to:

Cancellation flow

User cancels a plan which is refundable:

• For each subscription:
  • If the purchase is cancellable, it will be cancelled. This means auto-renew of the plugin will change to OFF
  • If the purchase is cancellable and refundable, it will be cancelled and refunded. This means the plugin is removed

User cancels a plan which is not refundable:

• For each subscription:
  • If the purchase is cancellable, it will be cancelled. This means auto-renew of the plugin will change to OFF
  • If the purchase is cancellable and refundable, it will not be refunded, just cancelled. This means auto-renew of the plugin will change to OFF

[epeicher]

The logic has been updated to reflect the latest comments. The Dialog wording has been kept generic:

[cpapazoglou]

Thanks for wrangling this @epeicher!

[a8ci18n]

This Pull Request is now available for translation here: https://translate.wordpress.com/deliverables/7561230

Thank you @cpapazoglou for including a screenshot in the description! This is really helpful for our translators.

[a8ci18n]

Translation for this Pull Request has now been finished.