-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No alert if payment is over $999.999.99 or under $0.50 -Card input fields are not rendered. #7485
Comments
@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. |
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. |
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? |
@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? |
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. |
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. 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. |
I see, thank you for clarifying!
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.
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. |
@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:
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. |
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.
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.
We can add some messaging next to the total - it's feasible. I think it could also help the customer. 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
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. |
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. |
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:
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?
B2B Shopper who MUST use a P-card to get level 3 data:
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:
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:
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? |
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. 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 I will provide some examples of the possibilities for the UI in the next sprint, unless somebody gets to this first. |
Description
Stripe (and thus WooPayments) have an upper limit of $999'999.99 per transaction limit.
BUT, there is no error or alert displayed if this is reached within the cart, on checkout, and the payment gateway just becomes inactive.
Acceptance criteria
Designs
Testing instructions
Dev notes
N/A
Additional context
Internal: 7135175
The text was updated successfully, but these errors were encountered: