Remove the need for the canMakePayment callback in the editor context

assets/js/base/context/providers/cart-checkout/payment-methods/use-payment-method-registration.ts

@@ -103,11 +103,15 @@ const usePaymentMethodRegistration = (
 				continue;
 			}
 
-			// In front end, ask payment method if it should be available.
+			// See if payment method should be available. This always evaluates to true in the editor context.
 			try {
-				const canPay = await Promise.resolve(
-					paymentMethod.canMakePayment( canPayArgument.current )
-				);
+				const canPay = isEditor
+					? true
+					: await Promise.resolve(
+							paymentMethod.canMakePayment(
+								canPayArgument.current
+							)
+					  );
 
 				if ( !! canPay ) {
 					if (

docs/extensibility/payment-method-integration.md

@@ -98,6 +98,9 @@ canMakePayment( {
 
 Returns a boolean value - true if payment method is available for use. If your gateway needs to perform async initialization to determine availability, you can return a promise (resolving to boolean). This allows a payment method to be hidden based on the cart, e.g. if the cart has physical/shippable products (example: [`Cash on delivery`](https://github.com/woocommerce/woocommerce-gutenberg-products-block/blob/e089ae17043fa525e8397d605f0f470959f2ae95/assets/js/payment-method-extensions/payment-methods/cod/index.js#L48-L70)); or for payment methods to control whether they are available depending on other conditions.
 
+`canMakePayment` only runs on the frontend of the Store. In editor context, rather than use `canMakePayment`, the editor will
+assume the payment method is available (true) so that the defined `edit` component is shown to the merchant.
+
 **Keep in mind this function could be invoked multiple times in the lifecycle of the checkout and thus any expensive logic in the callback provided on this property should be memoized.**
 
 #### `paymentMethodId`