@elizaan36 for awareness.

Not sure who'll be working on this, but here are some pointers: https://github.com/Automattic/woocommerce-payments/blob/develop/includes/payment-methods/class-affirm-payment-method.php#L34 on limiting min/max totals.

The way it works is to hide PM in UPE if the total does not fit the declared ranges. It's a pure client-side solution, but perhaps it can be used.

Thanks for flagging this! Not sure how often it occurs 😅, but an error notice at checkout is definitely needed if the payment won't succeed.

As a note, this would also be a good practise for payments below the minimum threshold, too. When adding currency conversions, a test transaction of less than 0.50 USD is also something that happens, and the customer just has no payment information, rather than a message stating that the minimum has not been met.
Reference: 7212772-zen

Hey all we've actually had Stripe eliminate the floor on their side as the $0.50 while well meaning impedes legitimate purchases that have been discounted through coupon codes, gift cards, rewards redemption.

I'm desperately looking for the other ticket that outlined the work we needed to do on our side to remove the hard coding we have in place that still prevents the sub $0.50 purchases.

According to Stripe, the new minimum is now the smallest subunit in the settlement currency. If the presentment currency is USD and settlement currency is USD, $.01 is the new minimum. If the presentment currency is the Mexican Peso and settlement is USD, $0.01 USD is the minimum.

Found it. https://github.com/Automattic/woocommerce-payments-server/issues/4137

This issue impacts checkout UI, so assigning to Heisenberg (based on team responsibilities Pc2DNy-3z-p2) @FangedParakeet. Assigning as part of Gamma Triage process PcreKM-yM-p2.

Tagging as part of re-evaluating older issues in the backlog, please have a look and close if no longer relevant.

To recap - this is how WooPayments' card element is rendered when the maximum amount is reached:

However, I have a feeling that it should now be up to the customer to "know" that the cart has an amount that the WooPayments plugin can't handle. The customer just wants to check out.

@pierorocca would it be reasonable to hide the card element (or any other UPE elements) if the amount is out of the limits, similar to what we do with BNPL methods?

Discussed at a Heisenberg meeting - a possible solution would be to show an error messaging at checkout when either of these conditions are met:

• WooPayments is set in dev mode
• WooPayments is not set in dev mode, but merchant is logged in

If WooPayments were the only payment gateway plugin configured on the merchant's site, WooCommerce would also show this message on the payment methods section:

@frosso we'd want to do everything possible to help a $1M transaction be executed. For this use case, hiding without an instructive message may not be sufficient to avoid shopper confusion. Hiding with a warning may be the best choice. Here's an example from the notifications documentation of inline messaging that we could replicate in the payments section. @nikkivias what are your thoughts?

For this use case, hiding without an instructive message may not be sufficient to avoid shopper confusion. Hiding with a warning may be the best choice.

I definitely think the message would need to be constructive and provide effective solutions. We don't know if there are multiple items in the cart, and splitting the cart into multiple transactions would be feasible for the customer.

It's also worth noting that customers may not be familiar with the intricacies of payment gateways.
Would a customer care about whether WooPayments can process their payment, if they can use a bank wire or another gateway on the merchant's store?
Would a customer consider the warning an obstacle, or possibly feel unable to continue with the checkout?
Should the WooPayments-specific warning message something the merchant should be able to enable/disable in the settings?
How would the WooPayments-specific warning play with the existing messaging from WC core that is displayed when there are no payment methods available?
( see screenshots here: #7485 (comment) )

My assumption @frosso, which may be incorrect, is that the shopper would want to make that $1M on a credit card as the primary method and expects every site to at least accept credit cards. e.g. a corporate purchasing card that has a high "open to buy" credit limit and requires L2/L3 data. A sophisticated B2B shopper will likely already know the rules about max limits (they used to be $99K several years ago) and that they should split payments. But those rules can vary by gateway implementation, Stripe's is a 12 digit limitation, so it's helpful to be explicit.

Speaking of the 12 digit limitation, this appears to be a limitation of settlement so it would apply to all payment methods.
The "There are no payment methods available" which would fire in this use case is too vague in my opinion.

When does the core error present? On page load or after placing the order? If we can determine that the total in the settlement currency exceeds 12 digits and we can work around the core error, I'd like to see an explicit message about Max total is exceeded and to split the purchase into 2 or more orders. Alternatively, automatically splitting the order would be ideal however I'd expect the complexity of that would not be worth the effort.

the shopper would want to make that $1M on a credit card as the primary method and expects every site to at least accept credit cards. e.g. a corporate purchasing card that has a high "open to buy" credit limit and requires L2/L3 data. A sophisticated B2B shopper will likely already know the rules about max limits (they used to be $99K several years ago) and that they should split payments. But those rules can vary by gateway implementation, Stripe's is a 12 digit limitation, so it's helpful to be explicit.

I see, thank you for clarifying!

Speaking of the 12 digit limitation, this appears to be a limitation of settlement so it would apply to all payment methods.
The "There are no payment methods available" which would fire in this use case is too vague in my opinion.
When does the core error present? On page load or after placing the order?

The error appears on the checkout page, on page load. The message is provided by WC core, because there are no registered payment methods that could handle the transaction.
If we were to add a messaging, it would need to be in addition to the one that is displayed by WC core - likely as a separate line item.
But keep in mind, the messaging we'd be providing would need to read well in all the following cases:

• in case there are no other payment methods registered
• in case there are other payment methods registered, but WooPayments can't handle the transaction

At this time, we have limit amounts baked in for BNPLs. When a transaction is beyond the BNPL limits, we're not displaying any messaging to the customer.
Would we need to ensure a messaging is displayed to customers also for BNPL methods?

in case there are no other payment methods registered

@frosso does Core differentiate between payment method registration and transaction eligibility that would be set by business rules (self or externally imposed) or merchant risk rules e.g. no transactions larger than $500?

If it does, then:

1. If there are no payment methods registered then the core error is fine.
2. If the credit/debit payment method is registered but the transaction value exceeds the max, I'd expect for the Core error not to fire and for WooPayments to be responsible for the notification and/or error handling.
3. For BNPL, I would not message about hitting an upper limit. The payment method messaging that we've implemented or are implementing across product, cart, and checkout pages is sufficient and since the shopper would have other alternatives, namely credit/debit in most realistic use cases.

If it does not, and Core throws this generic error, it smells a bit like an architectural limitation. I'd be curious how the domain architecture would handle this.

Could a workaround be to register the payment method and show an inline warning near the total or in the credit/debit payment method that the $1M (or whatever 12 digit value is exceeded) exceeds the maximum and to split the payment? Or option two, register it, attempt the transaction, and provide the appropriate error message when it fails/declines? See fraud max limit example below.

As an experiment I set my advanced fraud upper limit to $50 and got this error when attempting to process the transaction.

does Core differentiate between payment method registration and transaction eligibility that would be set by business rules (self or externally imposed) or merchant risk rules e.g. no transactions larger than $500?

There is differentiation, but WC core doesn't inquiry the payment method for an error message to be displayed to the customer, if the payment method is not eligible because of a set of business rules.

If it does not, and Core throws this generic error, it smells a bit like an architectural limitation.

Correct. If none of the enabled payment methods are eligible, WC core will act as if there are no payment methods, and it will display the "There are no payment methods available" message regardless.

Could a workaround be to register the payment method and show an inline warning near the total or in the credit/debit payment method that the $1M (or whatever 12 digit value is exceeded) exceeds the maximum and to split the payment?

We can add some messaging next to the total - it's feasible. I think it could also help the customer.
The next question would be: what if other plugins implement a similar solution? Would we find ourselves into the next "PRB stacking" nightmare we have on shortcode/do we just bring a bigger hammer to the table?

I agree with you that some convention in WC core to be adopted by all gateways is in order. I asked here for advice: p1709629701859539-slack-C3ECCGUVC

Or option two, register it, attempt the transaction, and provide the appropriate error message when it fails/declines? See fraud max limit example below.

I think that's also a good idea - I am unsure if there are built-in customization options for the message, but it should be feasible.

Would you say that the last option is the least disruptive / most aligned with how we handle various business rules and limitations today? If so that is the best way forward. This scenario is rare and in B2B buyers are aware of the limits and the error message does give a path to recovery.

On the min side, we got rid of the $.50 limitation on Stripe's side but I don't think internally the code has been updated yet for that change so failures are now probably unpredictable.

Would you say that the last option is the least disruptive / most aligned with how we handle various business rules and limitations today? If so that is the best way forward

I think it's the least disruptive option. But what would the UI look like, in this case?

Currently, if the transaction is above this limit, we're displaying saved tokens and the Stripe elements fail to load: #7485 (comment)

The UI would look like a regular checkout with a total <$1M. Rationale: Is this a case where the front-end restriction should be removed because Core provides no elegant way to guide the constrained experience? In my mind we're forced to allow the order to be placed, and to let the back-end respond with an error that we present to the shopper for action. If we don't have control over the constrained UI/UX, why introduce the constraint in the front-end?

In the domain driven model, do you know if or forsee other domains being responsible for some of these rules that currently happen in the front-end like upper and lower limits which may vary by processor?

The other alternative is to do nothing. Rely on the default core message and hope the shopper figures it out.

The $0.50 lower limit check on the front-end needs to be removed regardless. The lower limit now is the smallest currency unit in the settlement currency. e.g. $0.01 for USD/CAD/AUS. If there happens to be a case of like a $0.01 transaction that then settles into some even smaller mccy value, let the back-end response handle the error. Doesn't make sense to me to maintain code that's looking for a rare fractional of the smallest unit in a currency.

hey team, As has already been discussed in the thread the best approach would be to hide the payment methods and present a notice in the Payment options section to indicate that there are none available. I'll share a mockup, hopefully this helps. I think it's important to prevent the user from attempting to place the order if it won't be successful.

hey team, As has already been discussed in the thread the best approach would be to hide the payment methods and present a notice in the Payment options section to indicate that there are none available... I think it's important to prevent the user from attempting to place the order if it won't be successful.

I get it that's it's normally the best choice to hide an option that can't be used. This isn't a normal scenario unfortunately. My take is that it's important to best help the user recover from an error to get to success, which drives the revenue. The major constraint that doesn't make this "normal" is we don't have a way to control the error messaging that helps guide the shopper to success.

Here are the shopper paths I'm seeing with disabling the payment method and displaying the Core error message:

1. Page loads -> Shopper enters contact and shipping info -> Shopper sees core error "There are no payment methods available." -> Shopper abandons

2. Page loads -> Shopper enters contact and shipping info -> Shopper sees core error "There are no payment methods available." -> Shopper tries Google / Apple Pay -> Gets generic error on express checkout -> Shopper closes express checkout -> Shopper sees core error "There are no payment methods available." -> Shopper abandons

NOTE: Express Checkouts are not currently disabled if the credit/debit payment method is not available so users can get into different error states with various error messages. We'd have to have completely different logic added to monitor the cart total?

3. Page loads -> Shopper enters contact and shipping info -> Shopper sees core error "There are no payment methods available." -> Shopper tries WooPay -> Gets generic error on WooPay -> Shopper abandons or clicks "Checkout as guest" -> Shopper sees core error "There are no payment methods available." -> Shopper abandons

B2B Shopper who MUST use a P-card to get level 3 data:
4. Page loads -> Shopper enters contact and shipping info -> Shopper sees core error "There are no payment methods available." -> Shopper abandons

5. Page loads -> Shopper enters contact and shipping info -> Shopper only sees an offline banking option -> Shopper abandons

I don't see a scenario where this results in a success state and revenue generation unless the shopper figures out they must lower the cart value, based solely on the Core message we can't control.

The alternate path I'm proposing because it guides the shopper to success in all cases is:

1. Page loads -> Shopper enters contact and shipping info -> Shopper enters credit/debit info -> Shopper places order -> Sees error "Total amount supported by this payment method is $999,999 or less. Please try again with another payment method or split your purchase." -> Shopper tries again by splitting if they can OR Shopper understands why they have no paths forward and reaches out to the merchant to make alternate arrangements and we don't deny a merchant from a $1M+ sale.

Yes it's backwards to what we'd normally do and AFAIK from this discussion, is the only way we can get an error message that we can control @frosso ?

This setup then does create an oddity with express checkouts:

2. Page loads -> Shopper clicks WooPay -> On hosted checkout page load we display a tailored error -> Shopper clicks "Return to Cart" or maybe abandons

3. Page loads -> Shopper clicks Apple/Google Pay -> Shopper places order and gets a generic error -> Shopper closes express checkout -> Shopper sees error "Total amount supported by this payment method is $999,999 or less. Please try again with another payment method or split your purchase." -> Shopper tries again by splitting if they can OR Shopper understands why they have no paths forward

What am I missing? How do we get to revenue generation for the merchant and Woo rather than simply avoiding an error that doesn't lead to a sale?

I'm still investigating this.

One thing we can do is show the error message from Stripe when the customer attempts to place an order with a saved card.

I'm still investigating whether it's possible to customize (and elevate/show) the error message to display on page initialization, instead of failing to load the Stripe Elements like we do right now.

Thanks for continuing to investigate @frosso! Given this a few and far between use case on Woo stores, I trust your judgement to pickup other high impacting issues that are likely to impact the bulk of shoppers.

I couldn't find a way to catch Stripe's exception being thrown by their JS when the amount is too large.
I asked them here: p1710753503448859-slack-C9976E5MJ

In the meantime, I have a solution for when a saved card is used when the amount is too large: #8411

To follow up on this: we could leverage the loaderror event that is triggered on the payment element.

I will provide some examples of the possibilities for the UI in the next sprint, unless somebody gets to this first.

We could elevate the Stripe error message to replace the payment element UI. This way we can be compatible with scenarios where WooPayments is the only gateway available and in scenarios where there might be other payment gateways available (these are examples on TTF and Storefront themes):

If we were to elevate the messaging to the top of the page, and if there were other payment methods available, it would be unclear to the customer for which payment method the message would be related to.

I am still following up with Stripe for an alternative API that could work with their React Stripe.js API (which is used on our blocks checkout): p1711471130994119/1710753503.448859-slack-C9976E5MJ