Updating this first post since the cause is more evident now:

  • Having an addressfield present on the same page as the payment options.
  • Having more than 1 payment option (Credit Card, Check).
  • Leaving addressfield empty, and switching payment method.

/************************************************
Leaving the original post info below, actual issue above.
************************************************/

Only tested with multiple payment methods enabled & switching between the 2.
Might happen w/ all ajax calls during checkout, but I haven't tested.

Example use case to reproduce error:

  • Your site sells physical (shippable) products as well as file downloads.
  • You make a rule to hide shipping address & shipping service panes when the product in cart is type 'file download'.
  • During checkout, switch payment methods (which will perform an ajax call) and the shipping pane will be reset to enabled (not visible on the form though)
  • Submit / Continue checkout & it will throw error about the shipping fields not being filled out.

I can provide more info where needed. Also if you have any ideas on the cause, I'll gladly make a patch.
For now I have to switch back to using hook_commerce_checkout_pane_info_alter(), but I'd much rather use this.

CommentFileSizeAuthor
#8 1995782.payment_method_validation.patch688 bytesrszrama

Comments

MarcElbichon’s picture

MarcElbichon commented

#3 - You enabled shipping pane. In which case ?
Can you be more explicit about errors ?

jwjoshuawalker’s picture

jwjoshuawalker commented
Title: Pane settings lost during ajax call on checkout » Sometimes pane settings lost during ajax call on checkout
Project: Commerce Rules Extra » Commerce Core
Component: Code » Checkout

@MarcElbichon & Commerce Rules Extra

Sorry, false alarm. The problem persists even when using hook_commerce_checkout_pane_info_alter() to add/move/disable panes.

It also took a specific scenario here, the commerce_payment pane has to get put on the first page (checkout), with the customer_profile panes.

So, the actual example use here is making a 'donation / contribution' style experience with commerce. Only 2 pages to checkout, first for info & payment method, 2nd for review/confirm.

The setup looks like this:

Page 1 'checkout' panes:
-Billing info
-Payment

Page 2 'review' panes:
-Review

This is a conditional setup for when someone is buying a 'donation' product. Otherwise our setup has:

Page 1 'checkout' panes:
-Billing info
-Shipping info

Page 2 'shipping' panes:
-Shipping Service
-Payment

Page 3 'review' panes:
-Review

So to come back around, the problem is that when the shipping info pane is being conditionally disabled (via hook_commerce_checkout_pane_info_alter() or rules), if you switch payment methods (triggering ajax event), submitting the form will trigger a validation error that the Shipping info wasn't filled out (a disabled pane).

I will continue to do more testing.

jwjoshuawalker’s picture

jwjoshuawalker commented

Ok, it seems to be possible to throw a form validation error and have failure for payment_method to visibly change (after ajax call) as long as there is a customer_profile addressfield on the same page.

luksak’s picture

luksak
he/him
commented

I am experiencing this issue as well. My co-worker created an issue: #2015559: Unable to proceed past the first checkout step when selecting a different payment method Are you using the payment module as well? Disabling this module and using alternate payment methods solves the issue for me.

jwjoshuawalker’s picture

jwjoshuawalker commented
Component: Checkout » Payment
Category: feature » bug

@Lukas von Blarer

We are not using payment_commerce or payment modules. Only the core commerce_payment.

What triggers it in our case, is this scenario:

  • Having an addressfield present on the same page as the payment options.
  • Having more than 1 payment option (Credit Card, Check).
  • Leaving addressfield empty, and switching payment method.

This will throw a form error, but won't be seen until the next page load (e.g. the next checkout screen). Also, the payment method won't visibly switch like it should.

After testing thoroughly, I'm switching some of the settings on this issue. I am still unsure if payment or addressfield/checkout is the culprit, but at least we know how to reproduce.

jwjoshuawalker’s picture

jwjoshuawalker commented
Title: Sometimes pane settings lost during ajax call on checkout » Addressfield form validation error during payment method switch (ajax call) on checkout

Changing title to reflect the actual issue here.

rszrama’s picture

rszrama commented
Category: bug » support
Status: Active » Postponed (maintainer needs more info)

I just tested this locally with multiple payment methods and billing information on the same page, but I hit no form errors at all. Sure you don't have conflicting JavaScript on the page or some other error in the logs?

rszrama’s picture

rszrama commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)
StatusFileSize
new 1995782.payment_method_validation.patch688 bytes

Closing this for lack of further information or steps to reproduce. I have the Billing information checkout pane on the same page as Payment with two payment method options, but changing from one to another throws no error messages. If you can tell me exactly what modules, payment methods, and configuration you're using to throw these errors, I can attempt to recreate it locally. But with no way to reproduce the error, I can't effectively debug it.

If you want, you can test this patch and let me know if it mitigates the issue for you, but I'm not endorsing it as a full solution. Dunno if it would have any side effects.

jwjoshuawalker’s picture

jwjoshuawalker commented

Looks like you took care of it here: #2028195: Payment Method option is resetted when a user select a method and then interact with other pane with AJAX request

jwjoshuawalker’s picture

jwjoshuawalker commented
Issue summary: View changes

Updating to reflect the actual issue, so you don't have to find it in the comments.