Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.People writing custom checkouts will need a way to select a payment method / gateway. That means we need a "commerce_payment_method_select" form element.
That's not going to be easy.
We need to land these issues first:
#2827144: Support multiple payment gateways on Checkout Payment information pane
#2838380: [META] Allow offsite payment gateways to create and use payment methods
#2845072: Allow selection of payment method type for offsite payment gateways
Comments
Comment #2
bojanz CreditAttribution: bojanz at Centarro commentedComment #3
bojanz CreditAttribution: bojanz at Centarro commentedI've spent quite a bit of time struggling with this issue, and czigor wrote an initial patch over at (#2952193: Editing reusable payment methods.
We realized that the logic cannot be moved to a form element. Generally form elements have a #default_value, and a #value that is the result of the form editing process. Here it's unclear what both are. We have a list of gateways, and for onsite gateways the values are payment methods. For offsite/manual gateways, the values are payment gateways, with the additional collection of billing information. Having a form element that deals with several different entity types would be uncommon, and require hacks such as taking values only from $element['#payment_method'] and $element['#payment_gateway'] and $element['#billing_profile']. Even if we accepted that, I am not convinced in the form element also owning the collection of the billing profile, which a custom checkout flow might decide to handle in a different way. However, separating the collection of the billing profile from the form element is not easy, since the parent form would need to know the ID of the selected payment gateway before it is selected by the element process function. Finally, we had BC concerns about completely changing the structure of the PaymentInformation pane.
So, we've decided to take a more gradual approach. We shrink the PaymentInformation pane so that it's easier to copy & rework. We start by moving the payment option logic (which takes more than half of the pane codebase right now) into a PaymentOptionsBuilder. As a bonus, we cover it with kernel tests. We then rework PaymentInformation and PaymentAddForm to use it. A followup can then explore adding a trait that helps with building the actual form structure.
Comment #5
bojanz CreditAttribution: bojanz at Centarro commentedDevelopers can now swap the PaymentOptionsBuilder service to customize the options (labels, ordering, etc), leaving the main pane code alone, which is a big DX win.
Next stop is rerolling #2912996: Support admin order payments to use the new service on the admin side.